Transaction types

ABSTRACT

A Digital Transaction Processing Unit (DTPU) including one or more transaction applications operable for a digital transaction with a Digital Transaction Device (DTD), each of the one or more transaction applications being associated with identifying information, the identifying information being capable of identifying a subset of at least one transaction application within the one or more transaction applications, wherein the DTPU is operable, when conducting a transaction with the DTD, to communicate to the DTD the identifying information associated with one of the one or more transaction applications involved in the transaction.

CROSS REFERENCE TO RELATED APPLICATIONS

Continuation of International Application No. PCT/AU2020/050306 filed onMar. 27, 2020. Priority is claimed from Australian Application No.2019901029 filed on Mar. 27, 2019. Both the foregoing applications areincorporated herein by reference in their entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable.

NAMES OF THE PARTIES TO A JOINT RESEARCH AGREEMENT

Not Applicable.

FIELD OF THE INVENTION

The present invention relates generally to digital payment devices(DPDs). In at least some embodiments, the invention relates to methodsof configuring or operating DPDs.

In at least some embodiments, the invention may have application to DPDscapable of hosting credit cards, debit cards, mobile payment cards ornon-payment cards and/or documents (including licenses, ID cards,passports, and the like). In at least some embodiments, the inventionmay also have applications to DPDs which operate in conjunction with aDigital Assistance Device (DAD), such as a smartphone.

BACKGROUND OF THE INVENTION

Credit cards, debit cards and other types of physical cards or physicaldocuments often include a magnetic stripe which stores informationabout:

-   -   the card or document,    -   the holder of the physical card/document,    -   an institution which has issued the physical card/document, and    -   other information including card/document ID (for example, a        Personal Account Number (PAN)), expiry date, and the        card/document holder's name.

Physical credit/debit cards typically also have the name of thecardholder, the card expiry date and the PAN embossed or printed on thecard and may also include other security devices such as holograms. Suchphysical credit/debit cards are enabled for transactions with DigitalTransaction Devices (DTDs), such as Automatic Teller Machines (ATMs),Point-Of-Sale (POS) terminals, and Electronic Funds Transfer atPoint-Of-Sale (EFTPOS) terminals, where the digital transaction devicesare able to read the magnetic stripe when a user swipes the stripethrough or inserts the physical card into a device.

Some DTDs are operable with non-payment physical cards or documents toeffect non-payment digital transactions, including passport readers, ageverification card readers and the like.

More recently, physical cards, physical documents and other devices,such as watches and other wearable devices, have had integrated circuitchips, which can store some of the same (or similar) information as amagnetic strip, along with other information and with enhanced securityand with improved identifiers encoded in the chip. The chip in thesecards may be referred to as a Secure Element (SE). The card informationstored in the SE may be seen as a digital representation of the card ordocument, and is sometimes referred to as a digital card. A physicalcard with a SE may be referred to as a chipped card. A SE is sometimesreferred to as a finance chip which is issued by a financialinstitution, where it has sufficient hardware security.

A SE typically includes one or more of a Central Processing Unit (CPU),Read Only Memory (ROM), Random Access Memory (RAM), ElectricallyErasable Programmable Read Only Memory (EEPROM), a crypto-coprocessorand an Input/Output (I/O) system. In some SE chips a part of memory,sometimes referred to as user memory or tamper-resistant user memory, isset aside for storing applications and data particular to the operationsrequired for the cardholder and for the digital card.

A chipped card (and the SE thereon) may be enabled for contacttransactions and includes contact plates on a surface of the chippedcard which are connected for communication with the SE on the chippedcard. A contact transaction involves inserting (otherwise referred to as“dipping”) the chipped card into a DTD having complementary contacts tocommunicate with the chipped card contact plates. Contact transactionsare governed by EMVCo standards. A chipped card may also be enabled forcontactless transactions where the SE is connected to an antenna and theDTD has a corresponding antenna so that the SE and DTD can communicatevia ISO/IEC_14443 which is part of and compatible with a Near FieldCommunication (NFC) protocol when the chipped card is broughtsufficiently proximal to the DTD. Some payment devices are in the formof a wearable payment device, such as a watch, such a payment devicewill not have a contact plate and can only be used for contactlesspayment transactions. Many chipped cards, such as credit or debit cards,are operable for both contact and contactless digital transactions. Somechipped cards have a magnetic stripe with payment information encodedthereon, along with a SE.

In many circumstances the SE hosts a single payment applicationcomplying with EMVCo standards. Such SEs may be known as an EMV(Europay/Mastercard/Visa) chip. In this description of the prior art,for chipped cards and other chipped devices configured for paymenttransactions, the term SE should be understood to include SEs operableto host an EMVCo standards compliant payment application. Paymentapplications may also be referred to as applets, cardlets, applications,or payment instances. Payment applications are typically hosted in usermemory of the SE, for example, in the EEPROM of the chip.

Some SEs implement only a firmware layer in which all required card andcustomer details are encoded. Many more recent SEs (or SE/EMVs) areconfigured to host an operating system, which controls variousoperations of the SE. In some such SEs, the operating system iscompliant with a set of standards called GlobalPlatform (GP) CardSpecification standards (which will be referred to as GP or GPstandards), and such SEs are operable to also host payment applicationscompliant with EMVCo standards. MULTOS is another operating systemstandard for SEs on chipped credit and debit cards. SEs having a MULTOScompliant operating system are also used to host EMVCo compliant paymentapplications.

Some public transport travel cards include a SE which operates forcontactless digital transactions. Some documents, such as passports, mayinclude a SE which can be read by a device through a contactlesstransaction. Such non-payment transaction SEs are usually not operablefor hosting EMVCo compliant applications. However, such SEs may host anoperating system which is compliant with GP standards or MULTOSstandards.

During creation of a chipped card, data particular to the cardholder,such as the cardholder's name, PAN and other details, are written intothe SE in a process known as personalization by an agent known as aPersonalization (or Perso) Bureau. The data is sometimes referred to asperso data. Typically, the personalization of the SE involves writingthe perso data into a payment application (which has been previouslyinstantiated in the SE). In other circumstances, the perso data iswritten into a memory location of the SE which is accessible by apayment application.

Personalization usually includes one or several types ofpersonalization, each of which may be done in different stages. The maintypes of personalization are:

-   -   electrical personalization: which takes place during        provisioning, and which loads application codes, user data (such        as the cardholder's name, PAN and other details) and a        cryptographic key (for creating transaction cryptograms) into        the SE, which is locked on completion so that no further changes        can be made, with details of the personalization forwarded to        the issuer. Data is written to the magnetic stripe (if the card        has one); and    -   graphical personalization: the printing or embossing of text or        pictures on the chipped card and associated carrier product(s).

Typically, a payment application which has been personalized comprises adigital card in the SE of a chipped card.

In many SEs, GP commands/processes are used when installing a paymentapplication from a payment scheme (for example Mastercard, Visa, orAmerican Express), along with other aspects of a digital card, such asdata assigned to the customer from an issuer onto the SE of a chippedcard, including the PAN with issuer details.

Until recently, SEs in chipped cards have been operable with only asingle digital card type in a single payment scheme (and often with asingle payment application), for example, the DTC may operate as one ofa Mastercard credit card, a Mastercard debit card, a Visa credit card, aVisa debit card, or an American Express credit card, but cannot operatewith two or more digital card types and/or payment schemes.

In an SE which comprises finance compliant hardware (having sufficientphysical security to satisfy standards) and hosting a GP standardscompliant operating system, each application on the SE (includingpayment applications) has an associated unique Application IDentifier(AID). Each AID is composed of a Registered application providerIDentifier (RID), which is issued by the ISO/IEC 7816-5 registrationauthority, and a Proprietary application Identifier eXtension (PIX),which enables the application provider to differentiate among thedifferent applications offered. The AID may also be referred to as theApplication Definition File (ADF) name.

Communication with a SE chip is effected over interfaces through whichApplication Protocol Data Units (APDUs) are sent. The APDUs includecommand APDUs and response APDUs. APDUs are used for communications to aGP standards compliant operations system of a SE, which are sometimesreferred to as GP standard commands and GP standard responses, sometimesas GP commands and GP responses, or sometimes simply as commands andresponses. APDUs are also used for communication between the SE and aDTD (governed by ISO 7816, EMVCo and other standards), but are not thesame as APDUs for GP commands/responses.

For some payment digital transactions, the physical card (whether achipped card or magnetic stripe only card) need not be present, and onlyselected details from the card are provided to enable a transaction.Such transactions include internet transactions and Mail Order/TelephoneOrder (MOTO) transactions. For example, in a payment transaction acardholder provides details over the telephone (either via an automatedsystem or to a person), or via a secure internet portal, the detailstypically including the chipped card's PAN, the cardholder's name, thecard's expiry date, CVV, and other security information.

Security of payment transactions is a major concern as there have beenmany instances of fraudulent transaction with stolen physicalcards/documents or stolen physical or digital card/document details.Credit/debit cards may also have a CVV (or CVC on the magnetic stripe)to make it more difficult to replicate a card for fraudulent purposes.

For magnetic stripe cards (or chipped cards with a magnetic stripe), theCVC is usually a cryptogram, created based on the card data, forexample, including the card PAN and expiry date, and a bank's masterkey. The bank's authorization host recreates the CVC value with thebank's key to determine if it matches the CVC sent during a transaction.The CVC is printed on the card after personalization data is entered onthe card and is stored in the magnetic stripe.

The same principle was subsequently adopted for another CVC sometimescalled Card Verification Value 2 (CVV2), which is commonly printed inthe signature panel on the back of the card. The CVV2 is used primarilyto help secure e-Commerce and Internet or MOTO transactions. This is asecond unique cryptogram created from card data and the bank's masterkey (although this is a different cryptogram as compared with themagnetic stripe CVC). The CVV2 is not present on the magnetic stripe.

Often card issuers issuing chipped cards with a SE install acryptographic key thereon for generating a symmetric cryptographic keyin the SE, which is used during card communications with a DTD togenerate cryptograms (for example, Transaction Certificates (TCs)) for adigital transaction. The cryptograms (or TCs) sign the information thatthe transaction originated from an interaction with the SE on which thekey is installed.

Many chipped cards operate with a Cardholder Verification Method (CVM),such as a Personal Identification Number (PIN) code (as specified inmany regions) known only to the cardholder(s), which must be keptconfidential, and must be entered on secure and certified terminals toverify that the person is the authorized cardholder. Depending on theissuer's configuration, the PIN may be stored in the SE for offlineverification. The PIN may be stored locally in a secure, tamperresistant memory (that is, the SE). Other chipped cards having a CVM mayhave biometric security means, such as a fingerprint reader.

A SE is typically provided from a manufacturer with a plurality ofcontainers for different payment schemes. Containers are sometimesreferred to as libraries, Elementary Load Files (ELFs) or packages. Forexample, a SE may be supplied with three containers including Visa,Mastercard and American Express. Often these containers are in the ROMof the SE. Usually, as a requirement during personalization, containersrepresenting payment schemes, other than the container which is beingused for the payment application hosted on the SE of the chipped card,are disabled or made inactive during the personalization process after asingle digital card (the personalised payment application) is installedand made active. Containers provide a range of functions for a paymentapplication, called on when effecting a transaction with a DTD. In someimplementations, the container is a library of functions or classes (forexample, in a JavaCard).

Some finance compliant SEs with a GP standards compliant operatingsystem employ a security hierarchy in accordance with GP standards formanagement of contents of the SEs. The security hierarchy comprises atree of security domains, including an Issuer Security Domain (ISD),having the highest authority and control over the contents andoperations in the whole SE. The security hierarchy may also include oneor more Supplementary Security Domains (SSDs), each having subsidiaryauthority and control over a subset of the contents and operations ofthe ISD. The hierarchy may also include one or more SSDs which aresubsidiary to a higher SSD. Each security domain is implemented using anapplication which has its own AID. It is possible for a SE to haveseveral hierarchies, but only one ISD.

Each security domain may have an associated key (typically a symmetrickey) with a copy of the key stored in the corresponding security domainapplication and another copy of the key kept by (or is in the controlof) an entity (or agent) with authority over that security domain.

The ISD key for each SE may be a unique derivative of a master key ownedby an issuing authority, where the issuing authority's master key may beused for securing many SEs. The ISD key is generated by an issuingauthority for a SE and installed thereon so that the issuing authorityhas control over the ISD of the SE. The ISD may be passed from theissuing authority to another entity so that entity has control over theISD in the SE. In devices such a mobile phones with a SE, the owner ofthe ISD key passes the ISD key to a Key Management Server (KMS). SSDkeys generated by the KMS are installed on the SE. An agent with a keyfor a particular SSD has control over that SSD.

All ISD keys, SSD keys, and particularly the master key, are keptsecurely as secrets. Outside of the SE, an ISD key and/or a SSD key isin the possession of or in the control of an entity (or agent) withcontrol over the associated SSD. Otherwise, the ISD key and SSD keys arekept securely only in the SE (more particularly, in the security domainapplications). A key allows the possessor to effect one or moreoperations on a finance compliant SE with a GP standards compliantoperating system in the security domain associated to the key and inaccordance with privileges that are assigned to the security domain whenit is installed. When the possessor of a key is permitted to effect anoperation in a security domain, the possessor is said to be able toauthenticate to the security domain.

For a finance compliant SE with a GP standards compliant operatingsystem, operations on the SE are effected by scripts. Each scriptcomprises one or more APDUs. Typically, a script will be composed toeffect one or more operations (one or more commands) on the SE, and mayinclude one or more APDUs for effecting the one or more operations (orcommands). Some scripts do not require encryption as they do not need toauthenticate to a security domain. Other scripts require securing by akey for a security domain so that the script is able to authenticate tothat domain. Sometimes the script is also encrypted as well as beingsecured by a key for authentication to a security domain. When a scripthas its command(s) (that is, all its APDUs) effected on a SE (whether ornot in a security domain), this is sometimes referred to as playing orexecuting the script. The execution of a script includes: creating asecure session (using a session key derived from the security domainkey) with a SE to enable secure communication or transfer of the scriptto the SE, authentication to the target security domain in the SE, and,once transferred, authorization of a next step.

Each key set also has a counter which is incremented (to be the nextexpected counter value) after each script is authenticated to thatdomain. The purpose of the counter is to prevent replay (orre-execution) of a same script in the domain. The derivation of thesession key includes the counter value, so that when signing a script,the signing includes the counter value. If the counter value isincorrect, the derived session key will be incorrect, and the setup ofthe secure session will fail. Further, if the script is encrypted, anincorrect session key will not allow decryption.

Sometimes, scripts, such as those used for personalization of a paymentapplication, are not provided externally of a Perso Bureau. Instead, allscript operations for instantiating a payment application on the SE of achipped card, and for personalization of that payment application(becoming thereby a digital card on the SE of the chipped card) areconducted at the Perso Bureau (which may be during the lamination stageof chipped card manufacture or post lamination in a scheme approvedsecure area).

SEs and the chipped cards on which they are placed have lifecycles,including lifecycle states, including:

-   -   OP_READY: indicating a runtime environment is available and the        ISD, acting as the selected application, shall be ready to        receive, execute and respond to APDU commands (scripts);    -   INITIALIZED: an administrative card production state. The state        transition from OP_READY to INITIALIZED is irreversible;    -   SECURED: the intended operating card (both the physical/chipped        card and the digital card in the SE of the physical chipped        card) lifecycle state post-Issuance. This state may be used by        security domains and applications to enforce their respective        security policies. The state transition from INITIALIZED to        SECURED is irreversible;    -   CARD_LOCKED: present to provide the capability to disable the        selection of security domains and applications. The transition        from SECURED to CARD_LOCKED is reversible. Setting the card to        the CARD_LOCKED state means that the card shall only allow        selection of the application with the Final Application        privilege. Card content changes, including any type of data        management (specifically security domain keys and data), are not        allowed in this state; and,    -   TERMINATED: signalling an end of the card lifecycle and the        card. The state transition from any other state to TERMINATED is        irreversible. The state TERMINATED is used to permanently        disable all card functionality with respect to any card content        management and any life cycle changes. This card state is        intended as a mechanism for an application to logically (or        digitally) ‘destroy’ the card.

Some chipped cards have attempted to allow more than one magstripepersonality to be installed on a chip (typically, a non-SE, and even ifusing a SE, it is one which is not configured to host a EMVCo standardscompliant payment application and also which is not finance complianthardware, nor is the SE configured to host a GP standards compliantoperating system). In such proposals, a user is to select the magneticstripe card (not the same as a digital card as would be hosted by afinance compliant SE) with which the chipped card is to operate. Themagnetic stripe cards are installed “in the field” on the chipped card,duplicated from another physical card's magnetic stripe track 1 or track2 data. Multiple magnetic stripe cards may include more than one cardtype from the same payment scheme (for example, a credit card and adebit card from Mastercard), or may include card types in differentpayments schemes (for example, a Visa debit card and an American Expresscredit card). Example products include offerings from Plastc, Coin,Final, and Wocket. However, the Plastc solution had operationallimitations, and the Wocket solution requires a specific Wocket device.None of these solutions has gained wide market acceptance, and some havenow closed or ceased operating. One serious problem causing failure ofsuch prior solutions is not attaining certification from organizations,such as EMVCo, and thus are unsuited to operate with the correspondingpayment schemes requiring EMVCo certification and the DTDs in a paymentnetwork, which also require compliance with EMVCo standards. Anotherproblem facing such proposals is that the Service Code includes arequirement that a particular kind of chip is present, and the DTD mustrequest that this type of chip is used, however, as these cards haveonly a copy of the magnetic stripe (the magnetic stripe card), therequired type chip is not present, which will cause transactions tofail. Further, such proposals do not work because issuer (who owns thecardholders' data) cannot be convinced that:

-   -   the ISD keys and SSDs of the chip are tightly controlled by the        issuer only or an agreed agent of the issuer;    -   the issuer can use their SSD key (key rotation);    -   the card meets all the finance standards;    -   the card Is capable of holding the issuers data and is able to        securely generate issuer cryptograms;    -   the proposed cards are capable of having the data installed in a        secure personalisation bureau facility to the issuer's        specifications; and,    -   the lifecycle of the SE altered by the personalisation bureau is        locked to any other changes.

Another means of conducting payment transactions is known as a digitalwallet. A digital wallet refers to electronic devices and programs usedfor making payments for purchases digitally, without presenting aphysical credit card, debit card, or cash. One type of digital wallet isa device-based digital wallet implemented, for example, on a smartphone.Digital wallets may also be implemented on a wearable payment device.Examples of device based digital wallets include Apple Pay and SamsungPay. Google Wallet (G Pay) and PayPal provide apps which can operate onsmartphones. Device-based digital wallets implemented on NFC enableddevices such as smartphones can be used for contactless Card-Presenttransactions with suitably configured DTDs (contactless terminals).Another type of digital wallet is an internet-based digital wallet whichenables a user to add credit card/debit card information (that is,information readily obtainable from a physical card) allowing thecustomer to make online purchases. Google Wallet (for peer-to-peerpayments) and PayPal (for online payments) are examples ofinternet-based digital wallets. Digital wallets are provided to asmartphone user (or to the user of another device, or internet) by aWallet Service Provider (WSP). Typically, the user will requestestablishment of an account and is then provided the digital walletapplication for download onto the user's smartphone.

Digital wallets capable of conducting contactless payments and/orpeer-to-peer payments may contain a number of different paymentapplications for virtual payment cards (for example, Visa, Mastercard,American Express) or card types (credit card, debit card), which may bereferred to as Mobile Payment Cards (MPCs) and can be securely stored ina SE (typically an eSE or UICC chip) of the smartphone. Some digitalwallets can also be used to hold other non-payment cards, such as storeloyalty cards or gift cards. Collectively, the MPCs and non-paymentcards may be referred to a Virtual Cards (VCs), though non-payment cardswill not typically be stored in a digital wallet or in the more secureareas (sometimes referred to as payment areas) of memory on a SE.

There are differences between a MPC configured for a SE in a smartphoneor other similar mobile payment device and digital cards as hosted by aSE on a physical (chipped) card. A SE (an eSE/UICC chip) for paymentdevices, such as on smartphones, operates with a scheme containerwherein the container may be configured for operating only with MPCs,which are limited to contactless payment transactions (a digital card ina SE for a physical/chipped card must typically be able to performcontact and contactless payments). Containers are configured toinstantiate applications and/or create instances to suit the physicalform factor of the device (such as a chipped card or a smartphone) wherethey will be stored. A container on a chipped card can supportapplications/instances for contact and contactless cards for the schemeof that container, and a container for an eSE/UICC chip as used, forexample, on a smartphone, may support only applications/instances forcontactless virtual cards (or MPCs). A container for such an eSE/UICC iscapable of operating with more than one MPC, and the eSE/UICC of suchdevices is capable of operating with more than one container. Incontrast, a scheme container for a SE of a chipped card is limited tothe matching of the issued scheme of the single digital card to thescheme's container, wherein all other containers installed on the SE andnot containing the matched digital card are disabled or locked after thepersonalization process.

MPCs (and sometimes VCs or other applications and features) aretypically created, managed and distributed to a smartphone by an agent,including Trusted Service Managers (TSMs) and/or Token Service Providers(TSPs). The TSM/TSP is usually entrusted with authority to send MPCdata, including instructions for instantiating the payment applicationand cardholder personalization data (the instantiation andpersonalization are typically performed by different entities, but whichmay both be TSMs), Over-The-Air (OTA) via a Mobile Network Operator(MNO) using a secure channel to the user's smartphone. In addition toOTA communication, the TSM/TSP can send data Over The Internet (OTI), orOver The Wire (OTW) via, for example, a DTD. The secure channel isestablished according to GP standards protocols, for example SecureChannel Protocol 02 (SCP02), being a secure, private, and typicallysynchronous communication link between the TSM/TSP and the eSE/UICC chipon the smartphone.

Recently, another method to assist in providing MPCs has emerged calleda Secure Element Management Service (SEMS), an example being the NXPLoader Service, which uses digital certificates to ensure securetransfer of data from a provider agent to the eSE/UICC chip on thesmartphone.

A TSM may also receive tokens from a Token Service Provider (TSP) andother required card data from various parties, and uses these to createa MPC, which is made available to a cardholder through a secure link todownload onto the cardholder's smartphone.

There are different TSMs for performing different roles. A SecureElement Issuer (SEI) TSM (also referred to as a Root TSM) managesoperations on the SE of the user's smartphone or other type of mobilepayment device, including instantiation of payment applications andcreation of SSDs; and a Service Provider (SP) TSM manages creationdelivery of perso scripts to the user's smartphone or other type ofmobile payment device. The SP TSM may be a TSP, in which case the persoscript provided contains a tokenized PAN. In some circumstances, bothSEI and SP TSM roles may be performed by a single entity.

TSM/TSP operations are done by using one or more scripts issued by theTSM/TSP, which are encrypted by the TSM/TSP with a key forauthentication to a particular security domain on the eSE/UICC.

Many other operations available to Perso Bureaus and TSMs are notavailable to others. For example, when a user wishes to change theprimary MPC on their smartphone, the user must connect, for example,with a TSM to allow the TSM to perform required operations with a scriptto change the primary MPC in the digital wallet, which is then securelycommunicated back to the user's smartphone. This can be difficult if theuser is not in a location where a communication link to the TSM can beestablished.

As mentioned previously, a SE is in a CARD_LOCKED state before leaving aPerso Bureau and cannot be changed in the field. After the SE chip islocked only a Perso Bureau with the appropriate SSD key is able tochange the status.

Some smartphone SEs may require a Controlling Authority Security Domain(CASD) in the security hierarchy. The CASD exists to broker trustbetween the issuer of the SE and the issuer of the MPC to be hosted onthe SE. The CASD facilitates a key exchange between these two parties.Notably, SEs (or finance chips) on chipped cards do not have a CASDinstalled.

TSMs also assist with managing end-to-end communication and datatransfer security, for example, between the TSM itself, a bank(operating a cardholder's card accounts and other accounts), acredit/debit card provider (issuing the cardholder's card), a telecomscompany (providing a mobile network for the cardholder) and, insituations where the user's smartphone contains an eSE/UICC, thecardholder's smartphone.

A key ceremony is a task that is performed to support some of thefunctions of a TSM. The key ceremony is a standard procedure betweenparties who wish to securely share a secret. Secrets (such as ISD keysand the like) are generally held in a Hardware Security Module (HSM). Ina key ceremony, key custodians from different entities enter their partof a key into the HSM, which reconstructs the key in the HSM. Keys arecreated and encrypted inside the HSM (the keys are never unencryptedoutside the HSM). Now, both entities share a secret, which they may usefor encrypting a secure channel for communication to the SE.

The SP TSM is provided the account data (perso data) and converts itinto a APDUs formatted for a eSE/UICC in a smartphone, the TSM thenprepares the perso data (converted to APDUs) for download to thecardholder's smartphone and sends this to its own HSM to encrypt theAPDUs with the session keys (for example SCP02 session keys) for therespective SSD on the SE. The perso data is written into a paymentapplication to become a MPC.

The TSM uses master keys (residing in the HSM) in a Key ManagementSystem (KMS) to produce unique keys for a specific SSD in the SE of thesmartphone, or CDMA cell phones, and the NFC data package (comprisingAPDUs) is encrypted with the unique keys. The encrypted data istransferred Over-The-Air (OTA) to, for example, a Mobile NetworkOperator (MNO), which has performed a key ceremony as well.Alternatively, the data can be transferred via TLS. Also, the data mayalso be transferred OTI or OTW, where there is no MNO involved.

In an example operation, the MNO transfers the perso script (includingmetadata to display a card image on the phone's display with the last 4digits of the PAN) to the cardholder's smartphone or other mobilepayment device.

Checks may be performed including a check of the user's location, andchecks of device fingerprints (for example, the fingerprints of a SEwithin a smartphone). This process ensures that the bank and MNO canknow the data is authentic and delivered to the correct account holder.The data is decrypted and installed on the smartphone, after which thecardholder can use their smartphone for card payments. The processes andproducts of TSMs/TSPs, and their co-operating banks andtelecommunications providers have to-date been restricted to operatingwithin those organizations. For example, the MPCs instantiated andpersonalized on SEs through the secure end-to-end process are onlyavailable via those organizations and processes. If a card holder wishesto obtain a new MPC or change the operating card on their mobile device,it is commonly required to do this through the TSM/TSP and co-operatingorganizations.

As an alternative to the use of TSMs/TSPs is using a SEMS, an examplebeing the loader service which was developed by NXP Semiconductors N.V.Another example of a SEMS is implemented as a service in a recentrelease of GP standards. SEMS installs containers on the SE, but theperso data for instantiated payment instances must still be done by a SPTSM to create a MPC.

The NXP loader service was developed for the provisioning of wearablepayment devices and other smart devices using the Internet of Things(IoT). The NXP loader service requires a chip with NXP applicationsinstalled. Alternatively, if using a SEMS from the GP standards, NXPspecific applications will not be needed.

SEMS is available in a line of N×P chips and is preconfigured on the SEitself, as an applet and client. The loader services root entitydelegates content-management rights, using certificates. Applets can beloaded onto the SE without using a Secure Element Issuer (SEI) TSM. ForAndroid devices, the necessary scripts are already embedded into anAndroid application package (APK) and can trigger cardcontent-management services. For example, the scripts can createsecurity domains and inject keys, load and update applets (includingpayment applications), instantiate and customize the applet, and deletesecurity domains.

Despite the apparent convenience of digital wallets, each MPC in adigital wallet can only be used for contactless payments (and in someinstances, in online payments). Some POS/EFTPOS terminals do not supportthe type of contactless payment required and ATMs generally do notsupport contactless transactions. Further, not all smartphones supportNFC or digital wallets, and cannot be used for such transactions withany such DTDs. As a result, the establishment and use of digital walletshas experienced limited commercial success.

There is therefore an ongoing market need for chipped cards, such ascredit cards and debit cards (that is, having the shape of a traditionalcredit or debit card and having the contact plates and NFCinfrastructure of such chipped cards for contact and contactlesstransactions). However, a major disadvantage of chipped cards with a SEis that they cannot support multiple digital cards in the SE. Eachchipped card is supplied pre-installed with a single digital card whichis fixed for the life of the chipped card. Users must carry a separatechipped card for each digital card they wish to use.

Further, there is no known method or infrastructure for having a chippedcard (or other type of DPD) in the field with everything needed toprovision a new digital card (including instantiation of a new paymentapplication and personalization of that new payment application) to thechipped card, and/or for selecting and activating a personality frommultiple personalities hosted on the chipped card. Current methods ofprovisioning a new digital card to a chipped card (or other type of DPD)are only performed by the issuer in a highly secure environment.

Further, there is no method or infrastructure to form communicationlinks with chipped cards while in the field. There has been nomotivation to do so because such chipped cards have not operated withMPCs or to be supplied by TSMs, TSPs or SEMSs. Even though some chippedcards have been proposed to include communication functionality, suchchipped cards are also not able to form a direct or indirectcommunication link with a provisioning network (including TSMs, TSPs, orSEMSs). Current methods of loading a chipped card with a digital cardrequires a Perso Bureau with sufficient security to handle the issuers'banking SSD keys, bank cryptograms, private data and account data.Further, there has been no method or infrastructure to formcommunication links with chipped cards while in the field, and there hasbeen no motivation to do so as chipped cards have not operated withMPCs. Even though some chipped cards have been proposed to includecommunication functionality, such chipped cards are also not able toform a direct or indirect communication link with a provisioningnetwork, including TSMs, WSPs and TSPs, and other entities, agentsand/or providers in a card issuing, payment, and/or provisioningnetwork.

There is also no known method or infrastructure for provisioning achipped card in the field with everything needed to change to adifferent digital card while in the field (that is, remote from and notconnected to a provisioning network). As mentioned above, a SE for achipped card is deliberately placed in a CARD_LOCKED state beforeleaving a Perso Bureau so that it cannot be changed in the field. Evenif a SE were not locked before leaving a Perso Bureau, there is no wayto form communication links with chipped cards while in the field(remote from a provisioning network).

Yet another problem with some existing and/or some proposed chippedcards is that the means and/or methods they employ to host multipledigital cards or magnetic stripe cards on a SE are not compliant withany of the existing (including past and/or proposed/future) requiredstandards, such as GP standards and EMVCo standards. As such, theseexisting and/or proposed chipped cards will be unable to enter intodigital transactions with DTDs, which are required to interoperate onlywith compliant chipped cards.

Further, the existing and/or proposed chipped cards, if effectingdigital card changes as they specify, would fail when faced with a DTDwhich tries to effect direct selection as the DTD would be presentedwith a list of AIDs from all the installed digital cards or magneticstripe cards in the SE or other chip on the chipped card.

Yet another shortcoming, in some smartphones and other types of mobilepayment device using MPCs in digital wallets is that, when a user wishesto change between MPCs (for example, change from a MPC associated with aMastercard credit card to a MPC associated with a Visa debit card), theprocess of change commonly requires communication between the smartphoneand an agent such as a TSM. This can be inefficient for a cardholderwishing to make a quick change to the MPC of their multi-MPC smartphone.In some circumstances, a smartphone user will be in a location where itis not possible to make contact with the agent (TSM or other agent), andso it will not be possible to change the MPC of the smartphone. Further,as a TSM does not manage contact MPCs (or digital cards which havecontact and contactless interfaces) a cardholder cannot use the TSM tochange contact MPCs/digital cards.

Presently, payment applications on chipped cards and other paymentdevices are associated with only one account and are therefore limitedto a single transaction type, that is, payments from the one account.Presently, chipped cards and other payment devices are incapable ofhaving payment applications (or even non-payment applications)associated with more than one account, or account type in a financialinstitution such as a bank.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a Digital TransactionProcessing Unit (DTPU) including one or more transaction applicationsoperable for a digital transaction with a Digital Transaction Device(DTD), each of the one or more transaction applications being associatedwith identifying information, the identifying information being capableof identifying a subset of at least one transaction application withinthe one or more transaction applications, wherein the DTPU is operable,when conducting a transaction with the DTD, to communicate to the DTDthe identifying information associated with one of the one or moretransaction applications involved in the transaction.

In embodiments, the identifying information includes a tokenized primaryidentifier. In some such embodiments, the tokenized primary identifieris a tokenized Personal Account Number (PAN). In embodiments, theidentifying information includes a sequence number. In embodiments, theidentifying information includes an AID.

In embodiments, the identifying information corresponds to a transactiontype. In some such embodiments, the transaction type is a currency inwhich the associated transaction application is operable to conducttransactions. In embodiments, the transaction type is defined by a user.In embodiments, the transaction type corresponds to a user-definedtransaction category. In embodiments, each transaction type correspondswith a different account type hosted by a financial institution. Inembodiments, the financial institution associates each different accounttype with the primary identifier for the one or more transactionapplications.

In embodiments, the subset of at least one transaction applicationincludes a contact transaction application and a contactless transactionapplication.

In embodiments, each of the one or more transaction applications isoperable to conduct a transaction with a payment scheme, the one or moretransaction applications being operable to conduct a transaction withthe same payment scheme.

In embodiments, each of the one or more transaction applications isassociated with a corresponding primary PAN, the one or more transactionapplications being associated with the same corresponding PAN.

In embodiments, the DTPU is included on a Digital Payment Device (DPD).

In embodiments, the DPD is operable to reversibly unlock at least one ofthe one or more transaction applications, such that each of the at leastone of the one or more transaction applications is operable for adigital transaction with the DTD.

In embodiments, the DPD is operable to reversibly lock all others of theone or more transaction applications, such that each of the other one ormore transaction applications is inoperable for a digital transactionwith a DTD.

In embodiments, the DPD is operable by a user to select the at least oneof the one or more transaction applications to be locked.

In embodiments, the one or more transaction applications are associatedwith a Personalized Digital Transaction Package (PDTP), the DTPU beingoperable to host one or more PDTPs, each PDTP hosted by the DTPU beingassociated with a different primary PAN.

In embodiments, each hosted PDTP is associated with a correspondingpersonality hosted by the DPD.

In embodiments, each of the one or more transaction applications isassociated with a corresponding personality hosted at least in part bythe DPD, the one or more transaction applications being associated withthe same personality.

In embodiments, the one or more transaction applications comprises aplurality of transaction applications.

In a further aspect, the present invention provides a system forconducting digital transactions, the system including

-   -   a DPD including a DTPU in accordance with the first aspect of        the invention,    -   a transaction processing system which includes the DTD and is        operable to conduct digital transactions with the DPD.

In some such embodiments, the DPD is operable to communicate, to the DTDand the transaction processing system, the identifying informationcorresponding to a transaction application involved in a transactionwith the DTD.

In embodiments, the system is operable to report, to a user of the DPD,information indicative of the identifying information.

In embodiments, the transaction processing system includes one or morefinancial institutions. In some such embodiments, each transaction typecorresponds with a different account type hosted by one of the one ormore financial institutions. In embodiments, at least one of the one ormore financial institutions associates each different account type withthe primary identifier for the one or more transaction applications.

In yet a further aspect, the present invention provides a method ofoperating a Digital Transaction Processing Unit (DTPU) including one ormore transaction applications operable for a digital transaction with aDigital Transaction Device (DTD), the method including:

-   -   associating each of the one or more transaction applications        with identifying information, the identifying information being        capable of identifying a subset of at least one transaction        application within the one or more transaction applications,    -   communicating to the DTD the identifying information associated        with one of the one or more transaction applications involved in        the digital transaction.

Technical Platform and/or Related Technologies

The invention of the present specification operates in conjunction witha technical platform and/or related technologies, including technologiesand embodiments thereof which have or may have separate and independentinventiveness and patentability. The following is a description of thetechnical platform and/or related technologies, including a descriptionof terminology and description of some embodiments of the technicalplatform and/or related technologies.

Some parts of the description of the technical platform and/or relatedtechnologies may comprise and/or contribute to embodiments of thepresent invention.

Some parts of the description of the technical platform and/or relatedtechnologies may comprise and/or contribute to separately patentableinventions or embodiments of those separately patentable inventions.

The description of the technical platform and/or related technologiesshould not be taken as admission of prior art.

Digital Transaction Processing Unit (DTPU)

The term Digital Transaction Processing Unit (DTPU) is used in thepresent specification to indicate a broad range of Secure Elements (SEs)suitable for different embodiments of the present invention and inembodiments of its related technologies.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is configured to host, operate withand/or engage in digital transactions using at least one of a paymentPersonalized Digital Transaction Package (PDTP) and a non-payment PDTP.However, the description of the present invention focuses mostly onembodiments for payment PDTPs and related operations and configurations.Payment PDTPs include, for example, credit card PDTPs, debit card PDTPs,gift card PDTPs, and travel card PDTPs. Non-payment PDTPs include, forexample, passport PDTPs, age verification document PDTPs, and ID PDTPs.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is a finance card SE (sometimes referredto as an EMV chip). In other embodiments of the present invention and/orin other embodiments of its related technologies, the DTPU is a UICC oran embedded UICC (eUICC). In yet other embodiments of the presentinvention and/or in yet other embodiments of its related technologies,the DTPU is an eSE. In yet other embodiments of the present inventionand/or in yet other embodiments of its related technologies, the DTPU isan Integrated Secure Element (ISE). In further embodiments of thepresent invention and/or in further embodiments of its relatedtechnologies, the DTPU is implemented on a SIM. In yet furtherembodiments of the present invention and/or in yet further embodimentsof its related technologies, the DTPU is implemented on a smart microSD.

It will be understood that, the form of the DPD will render some formsof the DTPU as being more appropriate than others for that DPD. Inembodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is modified to suit the form of the DPD.In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is a modified or repurposed traditionalfinance card SE or EMV chip, configured to host more than one DTP/PDTP,wherein each DTP/PDTP has associated one or more transactionapplications.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to host at least one DTP/PDTP(and its associated one or more transaction applications) which areEMVCo standards compliant. Typically, transaction applications which areEMVCo standards compliant are payment applications (accordingly, theDTP/PDTP is a payment DTP/PDTP).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is configured to host an operatingsystem. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the operating system isGlobalPlaform (GP) standards compliant. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the operating system is JavaCard, which is GP standardscompliant. In other such embodiments of the present invention and/or inother such embodiments of its related technologies, the operating systemis MULTOS compliant. In some embodiments of the present invention and/orin some embodiments of its related technologies, the DTPU (along withother components of the DPD) is compliant with GP Card Specification.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is compliant with Payment Card Industry(PCI) standards. In other embodiments of the present invention and/or inother embodiments of its related technologies, the DTPU is compliantwith a Common Criteria (CC) protection profile.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to host at least one DTP/PDTP(and its associated one or more transaction applications) which areEMVCo standards compliant, and the DTPU is configured to host anoperating system which is GP standards compliant and/or JavaCardcompliant. In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU is operable to host atleast one DTP/PDTP (and its associated one or more transactionapplications) which are EMVCo standards compliant, and the DTPU isconfigured to host an operating system which is MULTOS standardscompliant.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTPU is operable for at least one of contactdigital transactions and contactless digital transactions.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the DTPU is a UniversalIntegrated Circuit Card (UICC) type chip or an eSE type chip (astypically used in mobile phones), wherein the DPD (particularly wherethe DPD is a DTC) and UICC/eSE are adapted so that the DTC (or, moregenerally, the DPD where appropriate) with UICC/eSE is capable ofperforming contactless and/or contact transactions. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the DTC (or, more generally, the DPD whereappropriate) is provided with components allowing the UICC/eSE toconduct contact transactions, such as external contact pads forcontacting respective pads in a DTD for communication between the DTPUand the DTD, and the DTC (or, more generally, the DPD where appropriate)is provided with a chip and one or more antennae, or a chip with one ormore antennae, allowing the UICC/eSE to conduct contactlesstransactions. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the chip is anexternal NFC chip that is operable for card emulation mode, and may be aCLF (contactless front end), wherein the CLF and eSE/UICC communicatevia an SWP connection. In other embodiments of the present inventionand/or in other embodiments of its related technologies, a UICC/eSErequires an MCU to operate with an NFC chip to cause the DTC (or, moregenerally, the DPD where appropriate) to operate in (card) emulationmode. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the NFC chip includes anantenna. In yet other such embodiments of the present invention and/orin yet other such embodiments of its related technologies, the DPDincludes a Secure Processing Module (SPM) which is a fully integratedone module solution for effecting communications between the DTPU andexternally of the DTPU, for example, via NFC and/or via the contactpads. In yet further such embodiments of the present invention and/or inyet further such embodiments of its related technologies, the SPM is aMCU within a SE. In yet other such embodiments of the present inventionand/or in yet other such embodiments of its related technologies, theSPM is a single chip including a SE, a Low-Power MCU, and a PowerManagement IC.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, for contact transactions, the DPD is provided withcomponents such as contact pads for contacting respective electrodes ina DTD for communication between the DTPU and the DTD. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the contact pads and/or their arrangement onthe DPD is ISO7816-2 compliant. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies, aDPD with contact pads for contact transactions is a DTC. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the DTC has a form substantially equivalent toa traditional credit/debit card form. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the DTC includes 6 contact pads. In some other suchembodiments of the present invention and/or in some other suchembodiments of its related technologies, the DTC includes 8 contactpads.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, for contactless transactions, the DPD is providedwith components such as a chip and an antenna (or a chip with anantenna) for communication with respective antennae in DTDs. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the UICC/eSE is adjusted forthe form factor of a physical card, including modifying the height ofthe UICC/eSE.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTPU can be provided to a cardholder in aselected lifecycle state. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the life cycle states include: INITIALIZED, SECURED, CARD_LOCKED, andTERMINATED. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the DTPU is operablefor the application lifecycle state of LOCKED. In embodiments of thepresent invention and/or in embodiments of its related technologies, theDTPU is operable to execute commands, including any one or more of:SELECT, INITIALIZE UPDATE, EXTERNAL AUTHENTICATE, STORE DATA, OP READY.In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU (in a DPD) is provided in OP_READY state.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DTPU is provided inOP_READY state to the card user. In other embodiments of the presentinvention and/or in other embodiments of its related technologies, theDTPU (in a DPD) is provided in INITIALIZED state. In yet otherembodiments of the present invention and/or in yet other embodiments ofits related technologies, the DTPU (in a DPD) is provided in SECUREDstate. In further embodiments of the present invention and/or in furtherembodiments of its related technologies, the DTPU (in a DPD) is providedin CARD_LOCKED state, wherein it can be selectively reverted to SECUREDstate and returned to CARD_LOCKED state, as operations require.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU includes sufficient memory (for example,user memory) to allow installation of an application selection module,at least one payment scheme container, and one or more DTPs/PDTPs perpayment scheme container. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the application selection module includes a PSE (or contact transaction)selection application and/or a PPSE (or contactless transaction)selection application. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, theapplication selection module is operable for functions additional toand/or different from functions of traditional PSE and/or PPSEapplications. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the applicationselection module is installed on the DTPU, wherein the DTPU has existingPSE and/or PPSE applications, such that the application selection moduleoverwrites the existing PSE and/or PPSE applications. In some other suchembodiments of the present invention and/or in some other suchembodiments of its related technologies, the application selectionmodule replaces the existing PSE and/or PPSE applications. In yet someother such embodiments of the present invention and/or in yet some othersuch embodiments of its related technologies, the application selectionmodule is adapted to co-exist on the DTPU with existing PSE and/or PPSEapplications, wherein the application selection module has a higherpriority than the existing PSE and/or PPSE applications. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the application selection module is installedon the DTPU, where the application selection module is adapted toco-exist on the DTPU with existing PSE and/or PPSE applications, theapplication selection module has different application identifiers(AIDs) for its applications from the application identifiers of existing(including existing standard) PSE and/or PPSE applications.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to accept provisioning(remotely or locally) from a Trusted Service Manager (TSM). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the TSM is in a provisioning network. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the TSM provisioning may beoperated synchronously, asynchronously or selectively both synchronouslyand asynchronously for communications between the TSM and the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to accept provisioning(remotely or locally) from a Token Service Provider (TSP). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the TSP is in a provisioning network. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the TSP provisioning may beoperated synchronously, asynchronously or selectively both synchronouslyand asynchronously for communications between the TSP and the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to accept provisioning(remotely or locally) from a SEMS service. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the SEMS is in a provisioning network. In embodiments ofthe present invention and/or in embodiments of its related technologies,the DTPU is operable with either one or both of an NXP SEMS service(loader service) and a GP SEMS service.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the DTPU is operable to acceptprovisioning from:

-   -   a hybrid TSM/SEMS service in a provisioning network, wherein the        provisioning of data to the DTPU from the provisioning network        is from either or both the TSM and SEMS service;    -   and/or a hybrid TSP/SEMS service in a provisioning network,        wherein the provisioning of data to the DTPU from the        provisioning network is from either or both the TSP and SEMS        service;    -   and/or a hybrid TSM/TSP service in a provisioning network,        wherein the provisioning of data to the DTPU from the        provisioning network is from either or both the TSM and TSP        service;    -   and/or a hybrid TSM/TSP/SEMS service in a provisioning network,        wherein the provisioning of data to the DTPU from the        provisioning network is from any one or more of the TSM, the TSP        and the SEMS service.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where provisioning to the DTPU is from a TSP, theTSP provides only one tokenized PAN for personalizing a DTP to be aPDTP. It will be understood that, traditionally, TSPs were configured toprovide a number of tokenized PANs to substitute for a primary PAN.However, in some such embodiments of the present invention and/or insome such embodiments of its related technologies, the tokenized PANdoes not substitute for a primary PAN in the personalization of the DTP,but may be seen as being the primary PAN for the personalization of theDTP to become the PDTP.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU is configured to hostone or more PDTPs each associated with two or more transactionapplications, and in which each transaction application is personalizedwith a different tokenized primary identifier (for payment transactionapplications, the tokenized primary identifier is a tokenized PersonalAccount Number or tokenized PAN). In such embodiments of the presentinvention and/or in such embodiments of its related technologies, a PDTPwith tokenized trasnaction applications may be referred to as atokenized PDTP. In such embodiments of the present invention and/or insuch embodiments of its related technologies for transactionapplications, each tokenized primary identifier (or tokenized PAN) isprovided by a TSP during personalization of the transaction application.In some such embodiments, the two or more tokenized PANs are provided bythe TSP during personalization of the DTP. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the DTPU is configured to automatically select one of theassociated tokenized PDTP transaction applications for the PDTP when thePDTP is selected to be the active PDTP of the DPD. In some suchembodiments, the automatic selection is random or pseudo-random from therange of two or more tokenized PDTP transaction applications. In othersuch embodiments, the selection is based on a pre-set order of thetokenized transaction applications in the range of two or more tokenizedtransaction applications. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,at least one of the two or more transaction applications is personalizedwith a primary identifier, and the remainder of the two or moretransaction applications are personalized with tokenized primaryidentifier.

It should be appreciated that, in embodiments of the present inventionand/or in embodiments of its related technologies, where tokenizedtransaction applicationsare used, such may provide for enhanced privacyand/or security as, for example with payment transaction applications,the actual PAN of the transaction application (or the PAN of theassociated PDTP and associated personality) is not revealed for adigital transaction. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, thegraphical display of the DPD (where optionally having a graphicaldisplay) may display only the PAN for the selected token personalizedtransaction application from the selected tokenized PDTP, but notdisplay the primary PAN of that tokenized PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some forms of DPD will not be appropriate forcontact transactions (such as wearable devices), and so the DTPU may berestricted to contactless or over-the-Internet digital transactions (forexample, payment digital transactions).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to host a plurality of PDTPs.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DTPU is provided on the DPDwithout hosting any PDTPs. In some such embodiments, the DPD with DTPUhosting no PDTPs is provided to a third-party, such as a bank or a cardissuer, and the bank or card issuer provides one or more PDTPs for theDTPU to host before being provided to a cardholder for use. In othersuch embodiments, the DPD with DTPU hosting no PDTPs is provided to acardholder, and the cardholder may optionally have provisioned one ormore DTPs/PDTPs from a remote provisioning network or agent forinstallation on the DTPU. In further such embodiments, the cardholdermay receive a DPD for which the DTPU already hosts one or more PDTPs,and the cardholder may optionally have provisioned one or more furtherDTPs/PDTPs from a remote provisioning network or agent for installationon the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is operable to accept for loading (orinstallation) one or more containers, each associated with a paymentscheme. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the installation of theone or more containers is able to be effected when the DTPU (and theDPD) is remote from the provisioning agent providing the one or morecontainers.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, installing a DTP/PDTP on the DTPU includesinstantiating one or more transaction applications associated with theDTP/PDTP on the DTPU, where the one or more transaction applications areassociated with a container on the DTPU. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the container provides functions required by the one ormore transaction applications for effecting digital transactions.

Digital Payment Device (DPD)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a Digital Payment Device (DPD) is any deviceoperable with a DTPU (and typically incorporating the DTPU) for digitaltransactions. Although the term DPD includes the term “Payment”, inembodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD may be used for both payment digitaltransactions and non-payment digital transactions.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes infrastructure for allowingprovisioning to the DTPU from a provisioning network. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the DPD includes infrastructure for allowingprovisioning to the DTPU from a provisioning network when the DPD (andthe DTPU) is remote from the provisioning network.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is a Digital Transaction Card (DTC) havingthe form of or a form like a traditional credit or debit card. DTCs (incard form) are typically operable for both contact and contactlesstransactions with a DTD, as well as over-the-Internet type transactions.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD has the form of a wearable device, such asa ring, a watch, a bracelet, or a necklace. Typically, such devices arenot operable for contact payment transactions, and are operable only forcontactless transactions with a DTD or over-the-Internet(card-not-present) type transactions.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DPD is a non-portabledevice, such as a fridge, a dishwasher, a washing machine, and othernon-portable equipment. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DPD is incorporated in the device. In other such embodiments of thepresent invention and/or in other such embodiments of its relatedtechnologies, the DPD is external to or remote from the device, butlinked to the device. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DPD maybe a payment device with a card-form (or partial card-form) part whichis linked to the non-portable device with a communication cable, whereinthe card-form is operable to be inserted (dipped) into a DTD for acontact payment. However, typically, such devices are not operable forcontact payment transactions, and are operable only for contactlesstransactions with a DTD or over-the-Internet type transactions.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, a DPD is incorporated into avehicle or is a tag for placement in a vehicle. Typically, such devicesare not operable for contact payment transactions, and are operable onlyfor contactless transactions with a DTD or over-the-Internet(card-not-present) type transactions.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DPD includes both a DTPU and a magneticstripe for holding information (this would typically be for suchembodiments where the DPD is a DTC). In some embodiments of the presentinvention and/or in some embodiments of its related technologies, themagnetic stripe is a dynamic magnetic stripe.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DPD includes a userinterface operable to control operations of the DPD (including one ormore components of the DPD, such as operations of the DTPU). In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the user interface includes oneor more buttons which a user can press to activate operations assignedto the one or more buttons.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the user interface includes aGraphical User Interface (GUI). The GUI may be a screen with low powerconsumption, such as an electronic paper display. In other suchembodiments of the present invention and/or in other such embodiments ofits related technologies, the GUI may be provided by an LCD display(including a segment display and/or an active matrix display). In yetother such embodiments of the present invention and/or in yet other suchembodiments of its related technologies, the GUI is adapted to display alogo or mark (including a trademark) of a payment scheme associated witha personality selected as the operating personality of the DPD. In thisregard, the GUI may be adapted to display multiple different logos ormarks, with the displayed logo or mark changed to match the paymentscheme associated with the personality selected to be the operatingpersonality of the DPD. In yet other embodiments of the presentinvention and/or in yet other embodiments of its related technologies,the user interface includes a slide sensor (or touch sensor) for sensingthe slide of a user's finger across the slide sensor to effect aselected operation on the DPD. In yet other embodiments of the presentinvention and/or in yet other embodiments of its related technologies,the user interface includes a touchscreen display in addition to orinstead of a keypad.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the user interface is operable for a user toselect one personality from the DPD (or select one PDTP on the DTPU)from amongst a plurality of personalities from the DPD (or plurality ofPDTPs on the DTPU).

In this specification, many embodiments and variations of the inventionand/or embodiments of its related technologies are described with a DTCas the DPD. However, it will be understood that, in many suchembodiments, the description applies to any form of DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes a receiver for receiving wirelesscommunications. In embodiments of the present invention and/or inembodiments of its related technologies, the DPD includes a transmitterfor transmitting wireless communications. In some embodiments of thepresent invention and/or in some embodiments of its relatedtechnologies, the DPD includes a transmitter coupled with the receiver.This may be referred to as the transceiver. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the transceiver is (or the transmitter and/or the receiverare) adapted to implement Bluetooth communication protocols. In othersuch embodiments of the present invention and/or in other suchembodiments of its related technologies, the transceiver is (or thetransmitter and/or the receiver are) adapted to implement WiFicommunication protocols. In yet other such embodiments of the presentinvention and/or in yet other such embodiments of its relatedtechnologies, the transceiver is (or the transmitter and/or the receiverare) adapted to implement Zigbee communication protocols. In yet othersuch embodiments of the present invention and/or in yet other suchembodiments of its related technologies, the transceiver is (or thetransmitter and/or the receiver are) adapted to implement NFCcommunication protocols. In further such embodiments of the presentinvention and/or in further such embodiments of its relatedtechnologies, the transceiver is (or the transmitter and/or the receiverare) adapted to implement two or more different communication protocols.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable to link with a DAD forintercommunication. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the linkbetween the DPD and the DAD is via Bluetooth or BLE. In other suchembodiments of the present invention and/or in other such embodiments ofits related technologies, the link between the DPD and the DAD is viaWiFi. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the link between the DPDand the DAD allows communication between the DPD and at least oneprovisioning agent from one or more provisioning agents in aprovisioning network, when the DAD is linked to the at least oneprovisioning agent for intercommunication. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the provisioning agent is a DPD manager.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable to link to at least oneprovisioning agent from one or more provisioning agents in aprovisioning network for intercommunication. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the link between the DPD and the at least one provisioningagent is via the internet using a WiFi transceiver on the DPD. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning agent is a DPDmanager. In some other such embodiments of the present invention and/orin some other such embodiments of its related technologies, the DPD isoperable to communicate with the DPD manager via a DPD manager gateway,the DPD manager gateway providing an interface for communication betweencomponents of the DPD manager and the DPD. In some further suchembodiments of the present invention and/or in some further suchembodiments of its related technologies, the communication between theDPD manager and the DPD is a secure communication link. In yet othersuch embodiments of the present invention and/or in yet other suchembodiments of its related technologies, the secure communication linkemploys Transport Layer Security (TLS). In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the secure communication link employs any one or more ofSecure Channel Protocols, including: SCP02 and SCP03. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the secure communication link employs SEMSsecurity certificates for securing the link. In yet other suchembodiments of the present invention and/or in yet other suchembodiments of its related technologies, the secure communication linkemploys two or more security layers. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, wherein one layer employs data encryption, including anyone or more of SCP02 (in embodiments, using SCP02 i=55 setting), SCP03(in embodiments, using AES encryption), and wherein another layeremploys Transport Layer Encryption (TLS), (for internet TCP/IP), which,in some embodiments, uses AES.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes an energy storage device. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the energy storage deviceincludes one or more batteries. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,in DPDs which have the form of a DTC, such batteries are flat formbatteries. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the battery is aflexible, printable and thin-type battery. In other such embodiments ofthe present invention and/or in other such embodiments of its relatedtechnologies, the energy storage device includes one or more capacitors,and may include one or more super capacitors. In yet other suchembodiments of the present invention and/or in yet other suchembodiments of its related technologies, the energy storage deviceincludes a combination of one or more batteries and one or morecapacitors. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, at least one of theone or more batteries is a primary battery. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, at least one of the one or more batteries is arechargeable battery. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DPD isoperable to recharge the at least one rechargeable battery using energyharvesting, including energy harvesting from a DTD during a digitaltransaction with the DTD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where the DPD includes contact pads, the contactpads comply with standards for contact pads on traditional credit and/ordebit cards. As such, SEs on physical cards (such as credit and debitcards) typically use contact pads on the surface of the card for datatransfer between the SE and a DTD in a payment/transaction network. Eachcontact plate has a number of pads for electrical signal (data)connection with corresponding electrodes in a DTD or other device. Theconfiguration and operation of many such contact pads is governed by astandard ISO/IEC 7816, which uses pads including: VCC, RESET, CLOCK,GROUND, and DATA pads to exchange APDU commands between a DTD and theDTPU of the DPD. As such, there are some pads not used for suchinteractions, including pads #4 and #8. Pads #4 and #8 (or the dataconnection channels between those pads and the DTPU) are available to beused in the present invention and related technologies of the presentinvention for data transfer between components on the DPD and externallyof the DPD. For example, pads #4 and #8 (or the data connection channelsbetween those pads and the DTPU) can be used for data communicationbetween the MCU and externally of the DPD. For example, in some suchembodiments, the MCU can be supplied with digital objects (includingscripts, metadata and other on-DPD files) from a DTD into which the DPDhas been dipped or inserted.

Digital Transaction Card (DTC)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is a Digital Transaction Card (DTC). Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD (or DTC) has a cardform, and is adapted for insertion (dipping) into DTDs. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the DPD (or DTC) has a card form, and isadapted for wireless (contactless) digital transactions with a DTD. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DTC has a traditional cardform, such as a traditional credit card or debit card.

Micro Controller Unit (MCU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD of the present invention has a MicroController Unit (MCU) which controls various components of the DPD, suchas a user interface, buttons of the user interface, a graphical displayof the user interface, a secure memory (for example, an OSE), acommunications module (including, for example, Bluetooth and/or WiFicommunications) and other components. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the MCU may also control select operations of the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is operable to receive signals from theuser interface of the DPD (including signals from buttons or other userinput devices) to effect operations on the DPD. For example, when a userof the DPD wishes to change the operating personality of the DPD, theuser presses the required button(s) on the DPD to effect such change,and the button(s) send signals to the MCU, which is operable to initiateactions on the DPD to change the operating personality, including (notnecessarily in this order) updating one or more registries on the DPD(including a MCU registry), locking all transaction applications (via anMCU-managed operation of the OSE and the DTPU), unlocking at least oneof the one or more transaction applications in the PDTP associated withthe selected personality (via an MCU-managed operation of the OSE andthe DTPU), updating the one or more selection applications in theapplication selection module (via an MCU-managed operation of the OSEand the DTPU), and displaying appropriate indicators of the nowoperating personality of the DPD via the user interface (the graphicaluser interface).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is compliant with any one or more of thefollowing certifications, protocols and/or standards: CC PP-0084 EAL4+and AVA_VAN.5 (it will be appreciated that such a MCU may be consideredan SE). In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the compliance is requiredfor storage and/or operation with data objects having a required levelof security, such as cryptographic keys and scripts.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU operates with low power consumption toassist in providing longer battery life for the DPD (if having anoptional battery). In embodiments of the present invention and/or inembodiments of its related technologies, the MCU is operable to acceptprovisioning from one or more of a DPD manager, a TSM, and a TSP(synchronously, asynchronously or selectively both synchronously andasynchronously). In some embodiments of the present invention and/or insome embodiments of its related technologies, the MCU is operable with aSEMS service to accept provisioning. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the MCU is operable with either one or both of an NXP SEMSservice (loader service) and a GP SEMS service to accept provisioning.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the MCU is linked forcommunication with the DTPU. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the MCU includes one or more communication pathways which are linked torespective communication pathways between the DTPU and the contact padsof the DPD (or DTC). In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, thecommunication pathways between the DTPU and the contact pads of the DPD(or DTC) include any one or more of: 1. VCC, 2. RESET, 3. CLOCK, 5.GROUND, and 7. DATA (as per ISO/IE 7816 standards).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is linked for communication externally ofthe DPD (or DTC) via contact pads of the DPD (or DTC). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU is linked for external communicationvia contact pads not used by the DTPU. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the MCU is linked for external communication via any oneor more of: contact pad 4 and contact pad 8 (as per ISO/IE 7816standards).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where the MCU is enabled for communicationexternally of the DPD (or DTC) using contact pads of the DPD (or DTC),the MCU is enabled to accept provisioning when the DPD (or DTC) isproximal to (and in physical contact with) a provisioning source. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning source is aDTD, and the DPD (or DTC) is inserted (or dipped) into the DTD, whereinthe DTD is enabled to provide digital objects to the MCU. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the provisioning source is located at alamination facility or some other such card manufacture facility,wherein the DPD (or DTC) is brought into contact with the provisioningsource (that is, the respective contact pads, such as contact pad 4 andcontact pad 8 (as per ISO/IE 7816 standards) are brought into contactwith corresponding electrodes), such that the provisioning source isenabled to provide digital objects to the MCU. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the digital objects include any one or more of: one ormore scripts (including encrypted and unencrypted scripts), metadatarelated to one or more DTPs/PDTPs for the DTPU, MCU firmware, firmwarefor other DPD components, and other DPD files.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is operable to securely store one or morescripts for execution on the DTPU, including one or more scripts capableof being authenticated by an SSD on the DTPU. In other embodiments ofthe present invention and/or in other embodiments of its relatedtechnologies, the MCU is operable to securely store one or more scripttemplates, the one or more script templates, each when written withfurther data, operable for execution on the DTPU. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU is operable to securely store one ormore cryptographic keys, each cryptographic key for encrypting (signing)a script or a script template (when written with further data) such thatthe script or script template (when written with further data) isauthenticatable by an SSD for execution on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is operable to receive from the DTPU oneor more sequence counter values (sometimes referred to as counters) fromone or more respective security domains (for example, SSDs). In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the MCU is operable to requestthe one or more sequence counter values from the DTPU. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU is operable to store one or morescripts to request the one or more sequence counter values from theDTPU. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the MCU is operable tostore one or more sequence counter value scripts and/or commands,wherein each script and/or command is sent to the OSE, such that the OSEprovides a sequence counter value request script and/or command to theMCU, which the MCU sends to the DTPU to retrieve a sequence countervalue for supply back to the MCU. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, each of the one or more sequence counter value commands isan unauthenticated command. In other embodiments of the presentinvention and/or in other embodiments of its related technologies, theMCU stores the one or more sequence counter value scripts and/orcommands, in which circumstance the MCU does not need to retrieve thesescripts and/or commands from the OSE.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is secured for storage and operation withscripts, script templates, and cryptographic keys. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU is in (or operates in) compliance withone or more GP standards and/or Common Criteria.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the MCU is operable to receivefrom an OSE one or more scripts, which the MCU sends to the DTPU forexecution. In yet other embodiments of the present invention and/or inyet other embodiments of its related technologies, the MCU is operableto receive from an OSE one or more encrypted scripts, which the MCUsends to an application under an SSD of the DTPU, wherein the one ormore encrypted scripts are authenticatable to the SSD. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU is further operable to request one ormore scripts from the OSE, the scripts for execution on the DTPU for anapplication under an SSD. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the MCU is operable to pass parameters to the OSE such that the OSE canwrite data to one or more template scripts. In some other embodiments ofthe present invention and/or in some other embodiments of its relatedtechnologies, the OSE is within the MCU. In further embodiments of thepresent invention and/or in further embodiments of its relatedtechnologies, the MCU and the DTPU are within a single IntegratedCircuit Chip (ICC). In yet other embodiments of the present inventionand/or in yet other embodiments of its related technologies, the MCU,the OSE and the DTPU are within a single Integrated Circuit Chip (ICC).In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the ICC includes a firewall forpreventing unauthorized communications between the MCU and the DTPU. Inother such embodiments of the present invention and/or in other suchembodiments of its related technologies, the ICC includes a firewall forpreventing unauthorized communications between the MCU, the OSE and theDTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU is operable as a proxy for securecommunication between one or more provisioning agents in a provisioningnetwork and the DTPU. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the securecommunication includes communication using secure protocols, includingany one or more of SCP02, SCP03, and other similar and/or related securecommunication protocols. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the secure communication protocol includes using SCP02 i=55.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where the MCU is operable as aproxy, the MCU is operable to receive digital objects, includingencrypted scripts, from one or more provisioning agents in aprovisioning network on a secure communication channel between the MCUand the one or more provisioning agents where the digital objects havebeen encrypted using SCP02 i=55. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the MCU, having received digital object encrypted using SCP02 i=55, isoperable to retain the received digital objects after the securecommunication channel is disconnected, the MCU is further operable tosend the digital objects to the DTPU for execution.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the MCU includes a MCU registry for storage ofmetadata, wherein the metadata is data related to one or morepersonalities hosted on the DPD (each personality associated with aDTP/PDTP hosted on the DTPU). In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the MCU registry includes one or more tables of metadata. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, a first MCU registry metadata table includescolumns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the MCU) for each entry in the table;    -   a personality index (an index for facilitating reference to each        personality on the DPD, each personality being associated with a        DTP/PDTP hosted in the DTPU);    -   a personality identifier (for payment card personalities, this        will be a PAN, including its Issuer Identification Number        (IIN));    -   a payment scheme name for each personality (where the        personality is for a payment card or the like);    -   an issuer name for each personality;    -   an expiry date for each personality;    -   a nickname for each personality;    -   a CVV for each transaction application in a PDTP associated with        a personality (where the personality is for a payment card or        the like);    -   a logo index for each personality (a reference to a logo to be        displayed on the DPD for each personality when it is the active        personality of the DPD);    -   a holder name for the personality (for payment cards or the        like, this is typically referred to as a cardholder name);    -   a personality activation state, which shows the present state of        each personality (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces);    -   a default personality activation state, showing what the default        state of activation for each personality should be in prescribed        circumstances, such as if the personality activation state is        somehow lost (this may use the following codes: 0: not default        for both contact and contactless interfaces, 1: default for        contact interface, 2: default for contactless interface, 3:        default for both contact and contactless interfaces);    -   a flag to indicate if the activation state/default activation        state of each personality has been changed; and    -   a head of AID list (being the address of the first AID for one        or more AIDs associated with transactions applications        associated to the DTP).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, a second MCU registry metadatatable includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the MCU) for each entry in the table;    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where each personality includestwo or more transaction types, the MCU first registry metadata tableincludes columns for one or more of:

-   -   a head of transaction type list (being the address of the first        AID for two or more AIDs each associated with a transactions        application for a transaction type associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includestwo or more transaction types, a further MCU registry metadata tableincludes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the MCU) for each entry in the table;    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a name for the transaction type;    -   a nickname for the transaction type (this may be the name        displayed on the DPD to indicate which transaction type is        active for an active personality, and may also be displayed on        the DPD for the purposes of the user selecting between different        optional transaction types);    -   an association for the transaction type (that is, what is the        transaction type associated to including: a bank account for        different purchase types from others of the transaction types        for the personality, a currency account for different currency        types from others of the transaction types for the personality,        and other associations);    -   an indication method (during a digital transaction there must be        a means for indicating to the bank or other institution        processing the transaction which transaction type is being used.        The indicators may include: a sequence number (which are        typically used to indicate primary or supplementary card        holders), or the AID of the transaction application associated        with the transaction type).    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where the DPD (and/or DTPU) is(are) configured to host one or more tokenized personalities (that is,wherein a personality has one or more associated tokenized transactionapplications, and wherein each tokenized transaction application has atokenized identifier (for payment card personalities, this will be atokenized PAN)), the first MCU registry metadata table includes columnsfor one or more of:

-   -   a head of tokenized transaction application list (being the        address of the first AID for two or more AIDs each associated        with a tokenized transactions application associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includesone or more tokenized transaction applications, a further MCU registrymetadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the MCU) for each entry in the table;    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a selection method which indicates how a tokenized transaction        application is to be selected from the one or more tokenized        transaction applications associated with a personality (which is        selected by the user for being the active personality), the        methods including: random or pseudo random selection        (automatically effected by the DPD without the user's input),        sequential selection (wherein the DPD automatically selects the        AID of the next tokenized transaction application on the list        for the selected personality, and user selection (wherein the        user selects the tokenized transaction application to be        activated for the selected personality to be activated).    -   a name for the tokenized transaction application (this would        typically only be relevant where user selection of the tokenized        transaction application is permitted);    -   a nickname for the tokenized transaction application (this may        be the name displayed on the DPD to indicate which tokenized        transaction application is active for an active personality, and        may also be displayed on the DPD for the purposes of the user        selecting between different optional tokenized transaction        applications. This would typically only be relevant where user        selection of the tokenized transaction application is        permitted);    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

Operational Secure Element (OSE)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes an Operational Secure Element(OSE) outside of a DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE is operable to securely store and/oroperate with one or more commands for execution on the DTPU, includingone or more commands encrypted for authentication to an SSD on the DTPU.In other embodiments of the present invention and/or in otherembodiments of its related technologies, the OSE is operable to securelystore and/or operate with one or more command templates, the one or morecommand templates, each when written with further data, operable forexecution on the DTPU. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the OSE isoperable to generate one or more commands from each of the one or morecommand templates. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the OSE isoperable to securely store and/or operate with one or more cryptographickeys, each cryptographic key for encrypting a command or a commandtemplate (when written with further data) such that the command orcommand template (when written with further data) is authenticatable toan SSD for execution on the DTPU. In embodiments of the presentinvention and/or in embodiments of its related technologies, the OSE isoperable to securely store and/or operate with one or more scripts forexecution on the DTPU, including one or more scripts encrypted forauthentication to an SSD on the DTPU. In other embodiments of thepresent invention and/or in other embodiments of its relatedtechnologies, the OSE is operable to securely store and/or operate withone or more script templates, the one or more script templates, eachwhen written with further data, operable for execution on the DTPU. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the OSE is operable to generateone or more scripts from each of the one or more script templates. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the OSE is operable to securelystore and/or operate with one or more cryptographic keys, eachcryptographic key for encrypting a script or a script template (whenwritten with further data) such that the script or script template (whenwritten with further data) is authenticatable to an SSD for execution onthe DTPU. It will be appreciated that such scripts are traditionallyused by entities such as TSMs, Perso Bureaus and the like for operationssuch as personalization.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the OSE is operable to storeand/or operate with digital objects other than scripts and cryptographickeys, such as firmware and/or files for other components on the DPD (forexample, MCU firmware and/or files).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE is located on the MCU, or on another chipin communication with the MCU on the DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE is compliant with any one or more of thefollowing certifications, protocols and/or standards: CC PP-0084 EAL4+and AVA_VAN.5. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the compliance isrequired for storage and/or operation with data objects having arequired level of security, such as cryptographic keys and scripts usedfor card management or SE management on the DTPU. In some suchembodiments, the separate OSE includes security firmware/architecture toenable storage of one or more security keys such that the storage andusage of the keys, and other OSE operations, at least meet requirementsof Common Criteria or PCI.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE is accessible only by the MCU to retrievedata, files and other digital objects, including scripts and encryptedscripts.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE is operable to receive from the MCUrequests to provide one or more scripts, one or more encrypted scriptsand one or more other digital objects, and to provide to the MCU therequested one or more scripts, one or more encrypted scripts and one ormore other digital objects. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the OSE is operable to receive from the MCU an identifier with eachrequest to identify which one or more scripts are required. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the identifier is an AID for an application(Including selection applications and transaction applications) in theDTPU. In some other such embodiments of the present invention and/or insome other such embodiments of its related technologies, where the MCUrequests a script or command from the OSE, which is generated,respectively, from a template script or a template command by the OSE,the MCU is operable to send an identifier with the request to identifythe template script or a template command to be used by the OSE.

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, the OSE is operable to receivefrom the MCU one or more parameters from the MCU for parameterizing (orwriting one or more parameters into) each of one or more templatescripts or template commands in the OSE. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the one or more parameters includes an AID of anapplication (Including selection applications and transactionapplications) in the DTPU.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the OSE is operable to receivefrom the MCU one or more counters representing the next expected countervalue for a key set in a security domain (for example, an SSD) of theDTPU.

In further embodiments of the present invention and/or in furtherembodiments of its related technologies, the OSE is operable to encryptone or more scripts with one of the one or more cryptographic keysstored in the OSE such that the one or more encrypted scripts areauthenticated to a security domain (for example, an SSD) of the DTPU.

In yet further embodiments of the present invention and/or in yetfurther embodiments of its related technologies, the OSE is operable toencrypt one or more scripts with one of the one or more cryptographickeys stored in the OSE and a counter such that the one or more encryptedscripts are authenticated to a security domain (for example, an SSD) ofthe DTPU, wherein the encryption includes the counter representing thenext expected counter value for the security domain.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the OSE is operable toparameterize (or write one or more parameters into) each of one or moretemplate scripts. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the one ormore parameters includes an AID of an application (Including selectionapplications and transaction applications) in the DTPU. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the OSE is operable to encrypt eachparameterized template script with one of the one or more cryptographickeys stored in the OSE. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the OSE is operable to encrypt each parameterized template script withone of the one or more cryptographic keys stored in the OSE and acounter, wherein the derivation of a session key from the cryptographickey for the encryption includes the counter representing the nextexpected counter value for the security domain.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the OSE includes an OSE registry for storage ofmetadata, wherein the metadata is data related to one or morepersonalities hosted on the DPD (each personality associated with aDTP/PDTP hosted on the DTPU). In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the OSE registry includes one or more tables of metadata. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, a first registry metadata table includescolumns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the OSE) for each entry in the table;    -   a personality index (an index for facilitating reference to each        personality on the DPD, each personality being associated with a        DTP/PDTP hosted in the DTPU);    -   a personality identifier (for payment card personalities, this        will be a PAN, including its IIN);    -   a payment scheme name for each personality (where the        personality is for a payment card or the like);    -   an issuer name for each personality;    -   an expiry date for each personality;    -   a nickname for each personality;    -   a CVV for each transaction application in a PDTP associated with        a personality (where the personality is for a payment card or        the like);    -   a logo index for each personality (a reference to a logo to be        displayed on the DPD for each personality when it is the active        personality of the DPD);    -   a holder name for the personality (for payment cards or the        like, this is typically referred to as a cardholder name);    -   a personality activation state, which shows the present state of        each personality (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces);    -   a default personality activation state, showing what the default        state of activation for each personality should be in prescribed        circumstances, such as if the personality activation state is        somehow lost (this may use the following codes: 0: not default        for both contact and contactless interfaces, 1: default for        contact interface, 2: default for contactless interface, 3:        default for both contact and contactless interfaces);    -   a flag to indicate if the activation state/default activation        state of each personality has been changed; and    -   a head of AID list (being the address of the first AID for one        or more AIDs associated with transactions applications        associated to the DTP).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, a second registry metadatatable includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the OSE) for each entry in the table;    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where each personality includestwo or more transaction types, the first OSE registry metadata tableincludes columns for one or more of:

-   -   a head of transaction type list (being the address of the first        AID for two or more AIDs each associated with a transactions        application for a transaction type associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includestwo or more transaction types, a further OSE registry metadata tableincludes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the OSE) for each entry in the table;    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a name for the transaction type;    -   a nickname for the transaction type (this may be the name        displayed on the DPD to indicate which transaction type is        active for an active personality, and may also be displayed on        the DPD for the purposes of the user selecting between different        optional transaction types);    -   an association for the transaction type (that is, what is the        transaction type associated to including: a bank account for        different purchase types from others of the transaction types        for the personality, a currency account for different currency        types from others of the transaction types for the personality,        and other associations);    -   an indication method (during a digital transaction there must be        a means for indicating to the bank or other institution        processing the transaction which transaction type is being used.        The indicators may include: a sequence number (which are        typically used to indicate primary or supplementary card        holders), or the AID of the transaction application associated        with the transaction type).    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where the DPD (and/or DTPU) is(are) configured to host one or more tokenized personalities (that is,wherein a personality has one or more associated tokenized transactionapplications, and wherein each tokenized transaction application has atokenized identifier (for payment card personalities, this will be atokenized PAN)), the first registry metadata table includes columns forone or more of:

-   -   a head of tokenized transaction application list (being the        address of the first AID for two or more AIDs each associated        with a tokenized transactions application associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includesone or more tokenized transaction applications, a further OSE registrymetadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the OSE) for each entry in the table (in other embodiments,        the DAD could store the metadata in a table, thus not requiring        the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a selection method which indicates how a tokenized transaction        application is to be selected from the one or more tokenized        transaction applications associated with a personality (which is        selected by the user for being the active personality), the        methods including: random or pseudo random selection        (automatically effected by the DPD without the user's input),        sequential selection (wherein the DPD automatically selects the        AID of the next tokenized transaction application on the list        for the selected personality, and user selection (wherein the        user selects the tokenized transaction application to be        activated for the selected personality to be activated).    -   a name for the tokenized transaction application (this would        typically only be relevant where user selection of the tokenized        transaction application is permitted);    -   a nickname for the tokenized transaction application (this may        be the name displayed on the DPD to indicate which tokenized        transaction application is active for an active personality, and        may also be displayed on the DPD for the purposes of the user        selecting between different optional tokenized transaction        applications. This would typically only be relevant where user        selection of the tokenized transaction application is        permitted);    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

DPD Hardware Security Architecture

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes a DTPU, an MCU and an OSE,wherein the DTPU is connected to the MCU for data communicationstherebetween, and the MCU is connected to the OSE for datacommunications therebetween. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the OSE is sufficiently compliant with standards for secure storage andoperations with cryptographic keys and scripts (including templatescripts).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the MCU is operable to managesome operations of the DTPU and the OSE, wherein the MCU instructs suchoperations on the DTPU by requesting one or more scripts stored on theOSE. The one or more scripts are passed through the MCU to be executed(or played) on the DTPU in a security domain (typically an SSD) in theDTPU, wherein the one or more scripts are authenticated against the SSD,and wherein the scripts are executed on an application in the securitydomain. In embodiments of the present invention and/or in embodiments ofits related technologies, a script can be executed directly against asecurity domain. In embodiments of the present invention and/or inembodiments of its related technologies, the MCU can request multiplescripts for multiple different domains (typically multiple differentSSDs) from the OSE for execution (or playing) on the DTPU.

It will be understood that the scripts (being encrypted scripts) storedon the OSE, if not alterable, must have their counters set to match thecounter expected by the target security domain of the DTPU (or the DTPUoperating system) for anti-replay security. In practice, this couldresult in the OSE being required to store a large number of scripts ifrepeated operations on the DTPU are required. In some embodiments of thepresent invention and/or in some embodiments of its relatedtechnologies, instead of storing a large number of scripts, the counterexpected by the DTPU can be reset, say to “0”, and the scripts stored onthe OSE can have their counters set from “0” upwards, so the samescripts can be replayed repeatedly.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the OSE can store one or morecryptographic keys for signing (encrypting) one or more templatescripts. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each cryptographickey is used to derive a session key, the derivation including thecounter, and the derived session key is used to encrypt a templatescript. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the one or more templatescripts are complete other than encrypting with a session key forauthentication to an SSD on the DTPU. When the MCU requests one or morescripts, the OSE is operable encrypt the one or more template scripts,each with a respective encryption key and counter used to derive asession key for the encryption.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the MCU can request multiplescripts for execution (or play) in multiple respective security domainsof the DTPU, so that, multiple respective cryptographic keys andrespective counters for the multiple respective domains are used toencrypt the multiple scripts. The encrypted scripts are then sent to theMCU to be passed to the DTPU for execution in the respective securitydomains of the DTPU. In yet other embodiments of the present inventionand/or in yet other embodiments of its related technologies, countersare associated to keysets which are associated to SSDs. SSDs can havemultiple keysets and therefore multiple counters.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the one or more templatescripts are complete other than having some required information, andbeing encrypted (with a session key derived from the encryption key andcounter). In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each template scriptrequires an AID associated with a target application (includingselection applications or transaction applications) to be passed as aparameter to the template script and requires having the counter set andbeing encrypted. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, when theMCU requests one or more scripts, it passes one or more parameters ofone or more AIDs for respective applications so that each of the scriptscan receive an AID, and then be encrypted by the respectivecryptographic key and counter for the security domain of the respectiveapplication.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the counter is passed as a parameter fromthe MCU when requesting a script from the OSE. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the counter may be obtained by the MCU by sending arequest (which is a script) to the DTPU. In other such embodiments ofthe present invention and/or in other such embodiments of its relatedtechnologies, the request may be made by script, so that the MCUinitially requests an expected counter request script from the OSE,sends the expected counter request script to the DTPU, the MCU receivesfrom the DTPU the expected counter, and then the MCU sends the expectedcounter as a parameter to the OSE for setting the counter of templatescripts (which is used in encrypting the scripts) in subsequent scriptrequests.

One advantage of this architecture is that a script remains secure inpassage through the MCU, which is required for compliance with somesecurity standards (such as PCI standards).

Cryptographic Key Secure Memory (CKSM)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD includes a secure memory for storing atleast one cryptographic key for establishing a secure communicationchannel or a secure communication session external of the DPD. Thissecure memory may be referred to as a Cryptographic Key Secure Memory(CKSM). In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the CKSM is operable togenerate or derive one or more session keys from each at least onecryptographic key. In some other such embodiments of the presentinvention and/or in some other such embodiments of its relatedtechnologies, the CKSM is operable to generate or derive one or moresession keys from each at least one cryptographic key and a counter fromthe DTPU.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the CKSM is operable to securely store asingle symmetric cryptographic key for establishment of a securecommunication session, wherein the secure communication session allowsthe DPD to be provided with further digital objects including any one ormore of: one or more scripts, one or more cryptographic keys forestablishing subsequent secure communications, and further firmware(including firmware upgrades to the MCU and other DPD components). Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, an initial symmetricalcryptographic key may be stored into (injected or written into) the CKSMduring manufacture or lamination (for a DTC only) of the DPD.

In some other embodiments of the present invention and/or in some otherembodiments of its related technologies, the CKSM is operable tosecurely store part of a single asymmetric cryptographic key pair forestablishment of one secure communication session, wherein the securecommunication session allows the DPD to be provided with further digitalobjects including any one or more of: one or more scripts, one or morecryptographic keys for establishing subsequent secure communications,one or more certificates, and further firmware (including firmwareupgrades to the MCU and other DPD components).

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the CKSM is operable to storefirmware for the DPD (for example, for implementing on the MCU whenfirst activating the DPD when the DPD is in the field, that is, in thehands of a user remote from a provisioning network). In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, the initial basic firmware for the DPD is storedon the MCU. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the initial basicfirmware allows basic operations of the DPD (operations managed by theMCU), such that, upon first provisioning the DPD, the MCU accesses thestored single symmetric cryptographic key and/or the stored part of asingle asymmetric cryptographic key pair in the CKSM to establish asecure communication session, and such that the DPD is operable toobtain by remote provisioning from one or more provisioning agents in aprovisioning network further firmware for implementation on the MCU. Thefurther firmware (including firmware upgrades to the MCU and other DPDcomponents) is provided securely to the MCU, and allows the MCU (and theDPD) to engage in more complex operations than would have been possiblewith the initial basic firmware, such as the DPD being provisioned withdigital objects including one or more scripts, one or more templatescripts, and one or more cryptographic keys. In embodiments of thepresent invention and/or in embodiments of its related technologies, thedigital objects include scripts and/or template scripts (and, ifrequired, cryptographic keys) for building (instantiating) applicationson the DTPU, including any one or more of: one or more security domainapplications (including SSDs), one or more containers (includingpackages or ELFs), one or more selection applications (including a PSEselection application and/or a PPSE selection application), and one ormore transaction applications (each belonging to or associated with oneof one or more DTPs/PDTPs).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the CKSM has a CKSM registry for storage ofmetadata, wherein the metadata is data related to one or morepersonalities hosted on the DPD (each personality associated with aDTP/PDTP hosted on the DTPU). Such a registry is similar or same as theregistries discussed above for the MCU and/or the OSE.

Data Assistance Device (DAD)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is adapted to operate with a DataAssistance Device (DAD). In embodiments of the present invention and/orin embodiments of its related technologies of the system, the systemincludes a DAD. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the DPD and theDAD each have transceivers for linking the DPD and the DAD to allowcommunication therebetween.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a user links the DAD to the DPD byoperating a user interface on the DAD and operating a user interface onthe DPD.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DAD includes one or more ofa smartphone, a tablet computer, or any other suitable mobile computingdevice. In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DAD includes non-mobiledevices, such as a personal computer. In yet other embodiments of thepresent invention and/or in yet other embodiments of its relatedtechnologies, the DAD includes a DTD adapted for communicating with theDPD via its receiver and/or transmitter.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DAD can link to the DPD,for example, by Bluetooth/Bluetooth Low Energy (BLE), by Near FieldCommunication (NFC), or by WiFi, and can establish a communicationsession to a remote agent, for example, via the internet.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD can be operated to effect communicationsbetween the DPD, via the DAD, and a remote agent, such as a provisioningagent. For example, the DAD may be used to effect communication betweena DPD and a Trusted Service Manager (TSM) via the DAD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD is operable to link with only onespecified DPD, and the DPD may be uniquely identified by any one or moreof: the ID of the DTPU, the ID of the MCU, and the ID of other DPDcomponents. In other embodiments of the present invention and/or inother embodiments of its related technologies, the DAD is operable tolink with multiple DPDs, each of which may be uniquely identified by anyone or more of: the ID of the DTPU, the ID of the MCU, and the ID ofother DPD components. In yet other embodiments of the present inventionand/or in yet other embodiments of its related technologies, the DPD isoperable to link with only one DAD, and the DAD may be uniquelyidentified by its device fingerprint, which may include itsInternational Mobile Equipment Identity (IMEI) number. In yet furtherembodiments, the DPD is operable to link with more than one DAD, each ofwhich may be uniquely identified by its device fingerprint.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DAD is operable tocommunicate with at least one of one or more provisioning agents in aprovisioning network. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DAD isoperable to communicate with a DPD Manager in the provisioning network.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DAD is operable tocommunicate with any one or more of a TSM, a TSP, and SEMS via the DPDmanager. In some other such embodiments of the present invention and/orin some other such embodiments of its related technologies, the DAD isoperable to communicate with the DPD manager via a DPD manager gateway,the DPD manager gateway providing an interface for communication betweencomponents of the DPD manager and the DAD. In some further suchembodiments of the present invention and/or in some further suchembodiments of its related technologies, the communication between theDPD manager and the DAD is a secure communication link. In yet othersuch embodiments of the present invention and/or in yet other suchembodiments of its related technologies, the secure communication linkemploys Transport Layer Security (TLS). In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the secure communication link employs any one or more ofSecure Channel Protocols, including: SCP02 and SCP03. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the secure communication link employs SEMSsecurity certificates for securing the link. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the secure communication link employs TLS and any one ormore of the Secure Channel Protocols for some communications, AESencryption for other communications, and TLS with further encryption foryet other communications.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD may effect communication between a DPD andat least one of one or more provisioning agents in a provisioningnetwork using any one or more of: a Mobile Network Operator (MNO)—as anactor, CAT-TP (Card Application Toolkit Transport Protocol), HTTP, SMS,Over The Air (OTA), and Over the Internet (OTI).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DAD can be a DTD. It will be appreciated that aDTD or its software will likely require modification for such purpose.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD is operable to setup parameters for theDPD in order to share or configure internet communications on the DPD,and in order to connect directly to at least one of one or moreprovisioning agents in a provisioning network. The internet connectioncould be:

-   -   sharing the internet access of a DAD via BLE;    -   having a WiFi chip on the DPD and connecting direct to the        provisioning agent (for example a TSM via an MNO) by sharing the        WiFi hotspot on the phone or connecting to a WiFi router (can be        seen as having the DAD on the DPD, but is a way of not requiring        a separate DAD for internet connection);    -   a Wifi2BLE bridge.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DAD is operable to host DADgateway software, wherein the DAD gateway enables the DAD be a bridgebetween the provisioning infrastructure (including the provisioningnetwork having one or more provision agents) and the DPD.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the DAD is operable to host aDAD application (sometimes referred to as a mobile application) forinterfacing with the user of the DAD (also being the user of the DPD),the DAD application enabling the user to perform operations on the DAD,some of which operations are effected to the DPD, either synchronously,when the DAD and DPD are linked for intercommunication, orasynchronously, wherein the DAD and DPD are later linked forintercommunication after an operation is entered into the DADapplication. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the DAD is operableto obtain (download) the DAD application from a mobile applicationportal of the provisioning network. In some other such embodiments ofthe present invention and/or in some other such embodiments of itsrelated technologies, the DAD is operable to obtain (download) the DADapplication from providers such as Google Play and Apple App Store. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the mobile application portalis a component of the DPD manager. In some other such embodiments of thepresent invention and/or in some other such embodiments of its relatedtechnologies, the DAD is operable to retrieve configuration files forthe DAD from the mobile application portal, including Bluetooth keys forthe DAD to link with (pair to) a specific DPD. In some further suchembodiments of the present invention and/or in some further suchembodiments of its related technologies, such configuration files wouldonly be provided after the specific DPD has been registered through themobile application portal and approved as being eligible for download tothe DAD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD is operable as a proxy for securecommunication between one or more provisioning agents in a provisioningnetwork and the DTPU on the DPD. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the secure communication includes communication using secure protocols,including any one or more of SCP02, SCP03, and other similar and/orrelated secure communication protocols. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the secure communication protocol includes using SCP02i=55.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where the DAD is operable as aproxy, the DAD is operable to receive digital objects, includingencrypted scripts, from one or more provisioning agents in aprovisioning network on a secure communication channel between the DADand the one or more provisioning agents where the digital objects havebeen encrypted using SCP02 i=55. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DAD, having received digital objects encrypted using SCP02 i=55, isoperable to retain the received digital objects after the securecommunication channel is disconnected, the DAD is further operable tosend the digital objects to the DPD for execution on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD includes a DAD registry for storage ofmetadata, wherein the metadata is data related to one or morepersonalities hosted on the DPD (each personality associated with aDTP/PDTP hosted on the DTPU). In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DAD registry is hosted on a secure memory chip in the DAD. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the memory chip is securedmemory, such as a secure element.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DAD registry includes oneor more tables of metadata. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies, afirst DAD registry metadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DAD) for each entry in the table (in other embodiments,        the DAD could store the metadata in a table, thus not requiring        the addresses);    -   a personality index (an index for facilitating reference to each        personality on the DPD, each personality being associated with a        DTP/PDTP hosted in the DTPU);    -   a personality identifier (for payment card personalities, this        will be a PAN, including its IIN);    -   a payment scheme name for each personality (where the        personality is for a payment card or the like);    -   an issuer name for each personality;    -   an expiry date for each personality;    -   a nickname for each personality;    -   a CVV for each transaction application in a PDTP associated with        a personality (where the personality is for a payment card or        the like);    -   a logo index for each personality (a reference to a logo to be        displayed on the DPD for each personality when it is the active        personality of the DPD);    -   a holder name for the personality (for payment cards or the        like, this is typically referred to as a cardholder name);    -   a personality activation state, which shows the present state of        each personality (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces);    -   a default personality activation state, showing what the default        state of activation for each personality should be in prescribed        circumstances, such as if the personality activation state is        somehow lost (this may use the following codes: 0: not default        for both contact and contactless interfaces, 1: default for        contact interface, 2: default for contactless interface, 3:        default for both contact and contactless interfaces);    -   a flag to indicate if the activation state/default activation        state of each personality has been changed; and    -   a head of AID list (being the address of the first AID for one        or more AIDs associated with transactions applications        associated to the DTP).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, a second DAD registry metadatatable includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DAD) for each entry in the table (in other embodiments,        the DAD could store the metadata in a table, thus not requiring        the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where each personality includestwo or more transaction types, the DAD first registry metadata tableincludes columns for one or more of:

-   -   a head of transaction type list (being the address of the first        AID for two or more AIDs each associated with a transactions        application for a transaction type associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includestwo or more transaction types, a further DAD registry metadata tableincludes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DAD) for each entry in the table (in other embodiments,        the DAD could store the metadata in a table, thus not requiring        the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a name for the transaction type;    -   a nickname for the transaction type (this may be the name        displayed on the DPD to indicate which transaction type is        active for an active personality, and may also be displayed on        the DPD for the purposes of the user selecting between different        optional transaction types);    -   an association for the transaction type (that is, what is the        transaction type associated to including: a bank account for        different purchase types from others of the transaction types        for the personality, a currency account for different currency        types from others of the transaction types for the personality,        and other associations);    -   an indication method (during a digital transaction there must be        a means for indicating to the bank or other institution        processing the transaction which transaction type is being used.        The indicators may include: a sequence number (which are        typically used to indicate primary or supplementary card        holders), or the AID of the transaction application associated        with the transaction type).    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where the DPD (and/or DTPU) is(are) configured to host one or more tokenized personalities (that is,wherein a personality has one or more associated tokenized transactionapplications, and wherein each tokenized transaction application has atokenized identifier (for payment card personalities, this will be atokenized PAN)), the first DAD registry metadata table includes columnsfor one or more of:

-   -   a head of tokenized transaction application list (being the        address of the first AID for two or more AIDs each associated        with a tokenized transactions application associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includesone or more tokenized transaction applications, a further DAD registrymetadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DAD) for each entry in the table (in other embodiments,        the DAD could store the metadata in a table, thus not requiring        the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a selection method which indicates how a tokenized transaction        application is to be selected from the one or more tokenized        transaction applications associated with a personality (which is        selected by the user for being the active personality), the        methods including: random or pseudo random selection        (automatically effected by the DPD without the user's input),        sequential selection (wherein the DPD automatically selects the        AID of the next tokenized transaction application on the list        for the selected personality, and user selection (wherein the        user selects the tokenized transaction application to be        activated for the selected personality to be activated).    -   a name for the tokenized transaction application (this would        typically only be relevant where user selection of the tokenized        transaction application is permitted);    -   a nickname for the tokenized transaction application (this may        be the name displayed on the DPD to indicate which tokenized        transaction application is active for an active personality, and        may also be displayed on the DPD for the purposes of the user        selecting between different optional tokenized transaction        applications. This would typically only be relevant where user        selection of the tokenized transaction application is        permitted);    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DAD registry is a copy of aregistry on the DPD, such as the MCU or OSE registry. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the MCU or OSE registry is a master registryto the DAD registry. In some other such embodiments of the presentinvention and/or in some other such embodiments of its relatedtechnologies, the DAD registry is a subset of a registry on the DPD,such as the MCU or OSE registry. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DAD registry operates as a backup of a registry on the DPD, such asthe MCU or OSE registry. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DAD registry is synchronized with the registry on the DPD, such asthe MCU or OSE registry, when the DAD and DPD are linked forintercommunication, wherein the registry on the DPD is the masterregistry.

Payment Schemes

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is configured to operate with one or morepayment schemes. Example payment schemes include Visa, Mastercard,American Express, and there are many others.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each payment scheme operational on a DTPU has anassociated container, which is used to create and install DTPs on theDTPU, wherein the DTP (and the PDTP, when the DTP has beenpersonalized), along with all the one or more transaction applicationsof the DTP/PDTP is associated with the payment scheme of the containerfrom which it was created. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,each container is hosted under a separate security domain. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the security domains for containers areUtility Security Domains (USDs), each USD being an application with anassociated AID, the USD hosting a container in its domain, eachcontainer having an AID. In embodiments of the present invention and/orin embodiments of its related technologies, where a domestic andinternational network exists for the same PDTP (or associatedpersonality of the DPD), 2 containers can be the base of a PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where provisioning a DTP/PDTP to a DTPU from aTSP, payment schemes have control of a security domain (an SSD). Inother such embodiments of the present invention and/or in other suchembodiments of its related technologies, a TSP has control of an SSD(and its related security domain). In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, transaction applications (or associated PDTPs) fromdifferent issuers have separate SSDs (sub-domains) under the paymentscheme SSD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where provisioning a DTP/PDTP to a DTPU from aTSM, the issuers TSM has control of a security domain (an SSD). In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, transaction applications (orassociated PDTPs) from different payment schemes have separate SSDs(sub-domains) under the issuer's TSM SSD.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where there is more than onepayment scheme concurrently hosted on the DTPU, the DTPU is operable toselectively operate with a subset of one or more of the one or morepayment schemes. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, each USDfor a containers associated with a payment scheme in the subset is in anunlocked state, and each USD for a containers associated with a paymentscheme outside the subset is in an locked state. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, a container with its USD in a locked statecannot extradite a transaction application instantiated by the containerinto an SSD in the part of the security hierarchy where transactionapplications are hosted. In this way, locking of the USD of a containereffectively disables the container and its associated payment schemefrom being able to install any transaction applications on the DTPU. Insome other such embodiments of the present invention and/or in someother such embodiments of its related technologies, a container with itsUSD in a locked state cannot instantiate a transaction application. Inyet other such embodiments of the present invention and/or in yet othersuch embodiments of its related technologies, transaction applicationsinstantiated before the USD is locked are able to keep operating, butafter the USD is locked no further applications can be instantiatedand/or extradited.

Provisioning Infrastructure

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each DPD is provisioned by a provisioninginfrastructure.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning infrastructureis configured to provision to each DPD when the DPD is remote from theprovisioning infrastructure. In some other such embodiments of thepresent invention and/or in some other such embodiments of its relatedtechnologies, the provisioning network is configured to provision toeach DPD when the DPD is proximal to the provisioning network (that is,the DPD can be brought into direct physical contact with at least a partof the provisioning network to be provisioned).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the provisioning infrastructure includesone or more entities, services and providers for performing roles asrequired for provisioning of a DPD (including any one or more componentsof the DPD, such as the MCU, the OSE, the CKSM, and the DTPU). Inembodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure further includesother entities, services and providers for performing roles as requiredfor provisioning of a DAD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore provisioning networks. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,each provisioning network includes one or more entities, services andproviders for performing roles as required for provisioning of a DPD(including components of the DPD, such as the MCU and the DTPU). In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, each provisioning networkincludes one or more provisioning agents. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, each provisioning network includes one or more DPDmanagers. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each one of the oneor more DPD managers is operable to manage one or more DPDs.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore issuers. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, at least oneissuer authorizes issuance of a DPD to a user. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, each such issuer is a card issuer or a financialinstitution. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each issuerauthorizes issuance of one or more digital cards or digital documentsfor installation on the DPD, wherein each digital card or each digitaldocument is represented by or included in a PDTP hosted on the DTPU of aDPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore DAD application portals (also referred to as mobile applicationportals). In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each DAD applicationportal is operable to provide digital objects to each DAD, such digitalobjects including digital files, firmware, software and DAD applications(sometimes referred to as mobile applications or apps). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, each DAD application portal is operable toprovide to each DAD a DAD application (sometimes referred to as a mobileapplication). In some such embodiments of the present invention and/orin some such embodiments of its related technologies, each DADapplication portal is operable to provide to each DAD a DAD gateway.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore factories. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, at least onefactory is operable to perform one or more of: manufacture of acomponent of a DPD, assembly of a DPD, lamination of a DPD (in the formof a DTC), and testing of a DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore key injection partners, each key injection partner operable toinject one or more cryptographic keys into a DPD. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, at least one of the one or more cryptographickeys are injected into the DTPU. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,at least one of the one or more cryptographic keys are injected directlyinto the DTPU. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, at least one ofthe one or more cryptographic keys are injected into the DTPU via theMCU. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, at least one of the one ormore cryptographic keys are injected into the MCU. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, at least one of the one or more cryptographickeys are injected into the OSE. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,at least one of the one or more cryptographic keys are injected into theSKSM.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore perso bureaus, each perso bureau operable for personalizing one ormore DTPs hosted on the DTPU of a DPD, wherein each DTP has one or moreassociated transaction applications which are each personalized by oneor more scripts provided by the perso bureau. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the perso bureau is operable for key injection forpersonalization of an SSD.

It will be appreciated that the one or more factories, the one or morekey injection partners, the one or more lamination factories, the one ormore perso bureaus, and other entities of the provisioninginfrastructure are configured to provide the physical DPDs (for example,in the form of a DTC) and to optionally pre-provision the DPDs beforethe DPDs are sent to their respective users.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning infrastructure includes one ormore provisioning networks interlinked for communication with one ormore issuers (including financial institution issuers). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, there is a one-to-many relationship between anissuer and multiple provisioning networks. In some other suchembodiments of the present invention and/or in some other suchembodiments of its related technologies, there is a one-to-manyrelationship between a provisioning network and multiple issuers. In yetsome other such embodiments of the present invention and/or in yet someother such embodiments of its related technologies, there is amany-to-many relationship between multiple issuers and multipleprovisioning networks. In further such embodiments of the presentinvention and/or in further such embodiments of its relatedtechnologies, there is a one-to-one relationship between an issuer and aprovisioning network. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the issueris a part of the provisioning network.

Provisioning Network

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each DPD is provisioned by a provisioning network.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning network isconfigured to provision to the DPD when the DPD is remote from theprovisioning network. In some other such embodiments of the presentinvention and/or in some other such embodiments of its relatedtechnologies, the provisioning network is configured to provision to theDPD when the DPD is proximal to the provisioning network (that is, theDPD can be brought into direct physical contact with at least a part ofthe provisioning network to be provisioned).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning networkincludes one or more entities, services and providers for performingroles as required for provisioning of a DPD (in including any one ormore components of the DPD, such as the MCU, the OSE, the CKSM, and theDTPU). In embodiments of the present invention and/or in embodiments ofits related technologies, the provisioning network further includesother entities, services and providers for performing roles as requiredfor provisioning of a DAD.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning networkincludes one or more provisioning agents.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the provisioning networkincludes a DPD manager for managing one or more operations on one ormore DPDs.

Provisioning Agent

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a provisioning network includes one or moreprovisioning agents. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, eachprovisioning agent is an entity or organization for providing servicesand digital objects to one or more DPDs (including DTCs). In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, each provisioning agent is an entity ororganization for providing services and digital objects to one or moreDADs.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each provisioning agent is one of a TrustedService Manager (TSM), a Token Service Provider (TSP), a Secure ElementManagement Service (SEMS), and a DPD manager.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, digital objects provisioned byeach provisioning agent includes one or more of: one or more commands(including GP commands), one or more scripts, one or more scripttemplates, one or more encryption keys, one or more files, and/or otherdata objects, such as data packets.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, each provisioning agentprovides to one or more DPDs when the DPDs are remote from theprovisioning agent (that is, while the DPD and DAD are in the field,typically in possession of a DPD/DAD user). In some other suchembodiments of the present invention and/or in some other suchembodiments of its related technologies, each provisioning agentprovides to one or more DPDs while the DPDs are proximal to theprovisioning agent (wherein the DPDs are yet to be in possession of aDPD user).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each provisioning agent is operable to receivefrom an issuer personalization data for one or more transactionapplications. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the provisioningagent is operable to convert the personalization data for eachtransaction application into one or more APDUs, wherein the one or moreAPDUs are written into one or more personalization scripts. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, each provisioning agent is operable to sendthe one or more personalization scripts for each transaction applicationto the DPD manager. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DPDmanager sends the one or more personalization scripts for eachtransaction application to the DPD for execution on the DTPU and forpersonalization of transaction application which has been instantiatedin the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, for transaction applications configured forpayment digital transactions, the personalization data includes, but isnot limited to, any one or more of: a PAN, a transaction key, acardholder's name, an expiry date, a PIN, a CVV, and other data for riskmanagement. In other embodiments of the present invention and/or inother embodiments of its related technologies, for transactionapplications configured for non-payment digital transactions, thepersonalization data includes, but is not limited to, any one or moreof: a unique identifier, a name of the relevant person, an expiry date,a PIN, and other data for risk management.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a DPD has a DTP hosted on the DTPU, and theDTP has one or more transaction applications associated therewith, eachprovisioning agent is operable to provide at least one personalizationscript for each of their one or more transaction applications forexecution on the DTPU, such that, when each transaction application ispersonalized it becomes a personalized transaction application and theDTP becomes a PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a DPD has a DTP hosted on the DTPU, and theDTP has one or more transaction applications associated therewith, andeach transaction application is to be associated with a differenttransaction type, each provisioning agent is operable to provide atleast one personalization script for each of the one or more transactionapplications, the at least one personalization script for eachtransaction application being capable of execution on the DTPU, whereinthe at least one personalization script for each transaction applicationincludes personalization data for its transaction type, such that, wheneach transaction application is personalized it becomes a personalizedtransaction application for a transaction type and the DTP becomes aPDTP. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the furtherpersonalization data for a transaction type for a personalizedtransaction application includes a sequence number which is differentfrom each other sequence number for one or more others of thetransaction types for the personalized transaction applications in thePDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a DPD has a DTP hosted on the DTPU, and theDTP has one or more transaction applications associated therewith, andeach transaction application is to be personalized with a tokenizedidentifier, each provisioning agent is operable to provide at least onepersonalization script for each of the one or more transactionapplications for execution on the DTPU, wherein the at least onepersonalization script for each transaction application includes datafor providing a tokenized identifier to the transaction application,such that, when each transaction application is personalized it becomesa tokenized personalized transaction application and the DTP becomes aPDTP. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, each provisioning agentfor providing the at least one personalization script for eachtransaction application including data for providing a tokenizedidentifier is a TSP.

DPD Manager

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the provisioning networkincludes a DPD manager for managing one or more operations on the DPD.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the one or more operationsinclude operations for instantiating one or more DTPs on the DTPU of theDPD. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, the one or more operationsinclude operations for delivering metadata to the DPD.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is operable togenerate digital objects additional to those provided by the traditionalprovisioning agents such as TSMs and TSPs, and to transmit such digitalobjects to a DPD. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DPDmanager is operable to transmit the digital objects to a DPD via a DAD.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is operable totransmit digital objects to a DPD directly, for example, via a WiFiconnection (that is, without a DAD). In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the DPD manager is operable to provide digital objects toat least one of the MCU, OSE, CKSM, and DTPU of a DPD.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is operable toreceive digital objects provided by one or more provisioning agents andto transmit those digital objects to a DPD.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is alsooperable to maintain a record of the state of a DPD, including a recordof each personality installed on the DPD, and characteristics of theDPD, for example the device model.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is operable toreceive requests from a cardholder (DPD user) for a new personality tobe installed on the DPD of the user, while the DPD is in the field (thatis, remote from the provisioning network or the provisioninginfrastructure), wherein installation of a personality includes theactions of: creating one or more SSDs (if required), instantiating oneor more transaction applications in the DTPU (wherein the one or moretransaction applications may be associated with a DTP), personalizingeach of the one or transaction applications on the DTPU (wherein the oneor more personalized transaction applications may be associated with aPDTP), and installing metadata on the DPD (in embodiments, on the MCU),the metadata associated with the transaction applications (and orDTP/PDTP), along with installation of metadata elsewhere on the DPD,along with installation of meta data on the DAD (if required), and alongwith installation of metadata in the provisioning network (such as onthe DPD manager) or in the provisioning infrastructure. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, a DAD is operable to transmit each suchcardholder (DPD user) request to the DPD manager, and the DPD manager isoperable to forward each such cardholder (DPD user) request to aprovisioning agent, which in turn is operable to forward each suchcardholder (DPD user) request to an issuer (wherein the issuer is theissuer related to the personality addition request). In suchembodiments, If the issuer approves the request, the issuer initiates aprocess in which DPD manager and at least one provisioning agent providedigital objects for installation on the DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD manager includes a DPD manager registryfor storage of metadata, wherein the metadata is data related to one ormore personalities hosted on the DPD (each personality associated with aDTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager registryincludes one or more tables of metadata. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, a first DPD manager registry metadata table includescolumns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DPD manager) for each entry in the table (in other        embodiments, the DPD manager could store the metadata in a        table, thus not requiring the addresses);    -   a personality index (an index for facilitating reference to each        personality on the DPD, each personality being associated with a        DTP/PDTP hosted in the DTPU);    -   a personality identifier (for payment card personalities, this        will be a PAN, including its IIN);    -   a payment scheme name for each personality (where the        personality is for a payment card or the like);    -   an issuer name for each personality;    -   an expiry date for each personality;    -   a nickname for each personality;    -   a CVV for each transaction application in a PDTP associated with        a personality (where the personality is for a payment card or        the like);    -   a logo index for each personality (a reference to a logo to be        displayed on the DPD for each personality when it is the active        personality of the DPD);    -   a holder name for the personality (for payment cards or the        like, this is typically referred to as a cardholder name);    -   a personality activation state, which shows the present state of        each personality (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces);    -   a default personality activation state, showing what the default        state of activation for each personality should be in prescribed        circumstances, such as if the personality activation state is        somehow lost (this may use the following codes: 0: not default        for both contact and contactless interfaces, 1: default for        contact interface, 2: default for contactless interface, 3:        default for both contact and contactless interfaces);    -   a flag to indicate if the activation state/default activation        state of each personality has been changed; and    -   a head of AID list (being the address of the first AID for one        or more AIDs associated with transactions applications        associated to the DTP).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, a second DPD manager registrymetadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DPD manager) for each entry in the table (in other        embodiments, the DPD manager could store the metadata in a        table, thus not requiring the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where each personality includestwo or more transaction types, the DPD manager first registry metadatatable includes columns for one or more of:

-   -   a head of transaction type list (being the address of the first        AID for two or more AIDs each associated with a transactions        application for a transaction type associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includestwo or more transaction types, a further MCU registry metadata tableincludes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DPD manager) for each entry in the table (in other        embodiments, the DPD manager could store the metadata in a        table, thus not requiring the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a name for the transaction type;    -   a nickname for the transaction type (this may be the name        displayed on the DPD to indicate which transaction type is        active for an active personality, and may also be displayed on        the DPD for the purposes of the user selecting between different        optional transaction types);    -   an association for the transaction type (that is, what is the        transaction type associated to including: a bank account for        different purchase types from others of the transaction types        for the personality, a currency account for different currency        types from others of the transaction types for the personality,        and other associations);    -   an indication method (during a digital transaction there must be        a means for indicating to the bank or other institution        processing the transaction which transaction type is being used.        The indicators may include: a sequence number (which are        typically used to indicate primary or supplementary card        holders), or the AID of the transaction application associated        with the transaction type).    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In other such embodiments of the present invention and/or in other suchembodiments of its related technologies, where the DPD (and/or DTPU) is(are) configured to host one or more tokenized personalities (that is,wherein a personality has one or more associated tokenized transactionapplications, and wherein each tokenized transaction application has atokenized identifier (for payment card personalities, this will be atokenized PAN)), the first DPD manager registry metadata table includescolumns for one or more of:

-   -   a head of tokenized transaction application list (being the        address of the first AID for two or more AIDs each associated        with a tokenized transactions application associated to the        personality, wherein each transaction application associated to        a DTP/PDTP hosted on the DTPU).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, where each personality includesone or more tokenized transaction applications, a further DPD managerregistry metadata table includes columns for one or more of:

-   -   an address (being a reference for a pointer to a memory location        in the DPD manager) for each entry in the table (in other        embodiments, the DPD manager could store the metadata in a        table, thus not requiring the addresses);    -   an address for the next AID;    -   an address for the associated (owning) personality;    -   a selection method which indicates how a tokenized transaction        application is to be selected from the one or more tokenized        transaction applications associated with a personality (which is        selected by the user for being the active personality), the        methods including: random or pseudo random selection        (automatically effected by the DPD without the user's input),        sequential selection (wherein the DPD automatically selects the        AID of the next tokenized transaction application on the list        for the selected personality, and user selection (wherein the        user selects the tokenized transaction application to be        activated for the selected personality to be activated).    -   a name for the tokenized transaction application (this would        typically only be relevant where user selection of the tokenized        transaction application is permitted);    -   a nickname for the tokenized transaction application (this may        be the name displayed on the DPD to indicate which tokenized        transaction application is active for an active personality, and        may also be displayed on the DPD for the purposes of the user        selecting between different optional tokenized transaction        applications. This would typically only be relevant where user        selection of the tokenized transaction application is        permitted);    -   an interface code (including 0: none (neither contact nor        contactless interfaces), 1: contact interface, 2: contactless        interface, 3: both contact and contactless interfaces);    -   an activation state (this may use the following codes: 0:        deactivated on all interfaces (contact and contactless), 1:        activated on contact interface, 2: activated on contactless        interface 3: activated on both contact and contactless        interfaces).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD Manager includes a DAD application server(sometimes referred to as a mobile application server) for providingapplications to a DAD (such as apps to manage operations of the DAD witha DPD, wherein the DPD is to be linked with the DAD). In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the DAD application server is operable as aninterface between the DPD manager gateway and the other components ofthe DPD manager (for example, the DPD content management system, the DPDapplication management system, and the DPD key manager). In some othersuch embodiments of the present invention and/or in some other suchembodiments of its related technologies, the DAD application server isalso operable to store configuration files for the DAD application(mobile application) installed on the DAD.

Digital Transaction Device (DTD)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTDs with which the DPD (typically in suchembodiments, a DTC) is operable to engage for digital transactions arePOS terminals or EFTPOS terminals (as they are called in Australia). Inother embodiments of the present invention and/or in other embodimentsof its related technologies, the DTDs are ATMs. In yet other embodimentsof the present invention and/or in yet other embodiments of its relatedtechnologies, the DTDs are personal computers, which may be equippedwith DTC readers. In yet further embodiments of the present inventionand/or in yet further embodiments of its related technologies, the DTDsare mobile devices, such as smartphones, which may be equipped with DPDreaders. In embodiments of the present invention and/or in embodimentsof its related technologies, for DPD including non-financial (ornon-payment) personalities, a DTD may include any one or more of: apassport reader, drivers license reader, and a transit agency validator.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTDs with which the DPD isoperable to engage for digital transactions are also adapted to operateas a Data Assistance Devices (DADs) to link to the DPD for communicationtherebetween and to provide data, commands, files and other digitalobjects and information between the DPD and the DTD (when acting as aDAD).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, where the DTPU of the DPD is operable tohost one or more transaction types associated with a PDTP and/or atokenized PDTP, some DTDs with which the DPD engages for a digitaltransaction are operable to display a list of available transactiontypes from which the DPD user or the operator of the DTD can select inorder to determine which of the transaction applications associated withthe selected transaction type are to be called by the DTD for thedigital transaction.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where the DTPU of the DPD isoperable to host one or more transaction types associated with a PDTPand/or a tokenized PDTP, some DTDs with which the DPD engages for adigital transaction are operable to automatically select a transactiontype. In some embodiments of the present invention and/or in someembodiments of its related technologies, the DTD is presented with acandidate list of transaction application identifiers (AIDs) withpriority indicators for each transaction application identifier, whereinthe DTD is operable to select the transaction application identifierwith the highest priority for the digital transaction.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, where the DTPU of the DPD isoperable to host one or more transaction types associated with a PDTPand/or a tokenized PDTP, the transaction type is selected on the DPD orvia the DAD in advance of presenting the DPD to the DTD for a digitaltransaction, in which case the DTD is provided only with the associatedone or more transaction applications associated with the selectedtransaction type either through the selection applications which are setwith the identifiers of the relevant one or more transactionapplications, or through direct selection (wherein all other transactionapplications are locked).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTDs with which the DPD is operable toengage for digital transactions are operable to build a candidate listof transaction application identifiers when presented with thetransaction application identifiers from one of the one or moreselection applications selected during a digital transaction.

Issuer

In embodiments of the present invention and/or in embodiments of itsrelated technologies, an issuer is a party that authorizes a paymentservice to be provided by a DPD. In other embodiments of the presentinvention and/or in other embodiments of its related technologies, anissuer is a party that authorizes a non-payment service to be providedby the DPD, such as a passport issuer. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, an issuer may be a financial institution or a party with abanking license. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the issuerauthorises the provisioning network to provision the DPD while in thefield.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, at least one issuer of the oneor more issuers authorizes issuance of a DPD to a user. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, each issuer authorizes issuance of one or moredigital cards or digital documents for installation on the DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the issuer issues the DPD to a cardholder (or DPDuser). In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DPD is issued by anotherauthorized provider (sometimes referred to as an additional card issueror distributor). However, in this specification the system will beexemplified with an initial card issuer.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the provisioning infrastructureis operable with multiple issuers (for example, issuers for manydifferent banks and/or financial institutions). In yet other embodimentsof the present invention and/or in yet other embodiments of its relatedtechnologies, the provisioning network may be associated with a singleissuer.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, an issuer will retain authority to deal with aPDTP which is hosted on a DPD. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the issuer has security control over at least a part of the DTPU. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, this control may be implementedby allowing the issuer to have authority over one or more SSDs in theDTPU by having the SSD key for each of the SSDs. In other embodiments ofthe present invention and/or in other embodiments of its relatedtechnologies, an issuer is operable to delegate authority to deal with aPDTP which is hosted on a DPD, including security control over at leasta part of the DTPU, and to have authority over one or more SSDs in theDTPU by having the SSD key for each of the SSDs. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, such delegation is to a TSP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the issuer may also have control (being the owner)of a transaction key used for personalization of a PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, an issuer may have a primary purpose other thanfinancial, but an interest in issuing financial instruments (includingcredit and debit cards) to customers. For example, a ride share providermay be an issuer, where it issues cards for payment of rides. In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, an issuer may be an entity or organization whichprovides non-financial documents, such as IDs, passports, and ageverification cards.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, issuers are outside of theprovisioning network, but in communication with the provisioning networkto provide required digital objects, such as personalization data and/orpersonalization scripts.

In further embodiments of the present invention and/or in furtherembodiments of its technologies, an issuer includes one or more of a TSMand a TSP.

Security Hierarchy

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU is provided with a security hierarchywherein the highest authority is allotted to the Issuer Security Domain(ISD), and each security domain lower than the ISD are referred to asSupplementary Security Domain (SSD). The SSDs or the security domainsunder the SSDs in the hierarchy may also be referred to as nodes. In yetother embodiments of the present invention and/or in yet otherembodiments of its related technologies, a DTPU may include multiplesecurity hierarchies. In embodiments of the present invention and/or inembodiments of its related technologies, the DTPU is provided with asecurity hierarchy wherein the first application installed is allottedto the Issuer Security Domain (ISD).

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, each domain in the securityhierarchy is secured with a cryptographic key (in embodiments, asymmetrical key), which allows access to that security domain foroperations therein only by a party or parties which have access (orownership) of the same cryptographic key. When a party has or hasauthority or control over a security domain, this typically means thatparty has in its possession or in its control the cryptographic key forthat security domain, such that the party is able to encrypt (or sign)scripts with that cryptographic key so the encrypted scripts will targetthat security domain (or any one or more applications directly underthat security domain) and authenticate to the SSD to be allowed toexecute operations under that security domain.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each bank (or financial institution), or issuingauthority, or NBIA third party with a presence on the DPD (or on theDTPU) may have a different SSD in the DTPU security hierarchy.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the security hierarchy isconfigured to allow one or more third parties, each of which is not abank or issuing authority, to personalize applications on the DTPU. Suchthird parties may be referred to as Non-Bank/Issuing Authority (NBIA)third parties.

Typically, a bank or issuing authority, or NBIA third party, SSD willreside under the ISD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each bank, issuing authority, or NBIA may becapable of hosting PDTPs or transaction applications within a number ofdifferent payment schemes or a number of different non-payment schemes.For example, “Bank A” may be capable of hosting PDTPs or transactionapplications using Visa and Mastercard, “Bank B” may be capable ofhosting PDTPs or transaction applications using Visa, Mastercard andAmerican Express. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, eachpayment or non-payment scheme hosted by a bank or issuing authority maybe under its own separate SSD, wherein each of the payment ornon-payment scheme SSDs are directly under the SSD of the bank orissuing authority.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, on a DTPU there could be an SSDfor “Bank A”, and the domain of “Bank A” includes a “PDTP A1” (forexample, a credit card PDTP) under “Payment Scheme A1” (for example,Visa), the domain of “Bank A” also includes a “PDTP A2” (for example, adebit card PDTP) under “Payment Scheme A2” (for example, Mastercard).The DTPU could further include an SSD for “Bank B”, and the domain of“Bank B” includes a “PDTP B1” (for example, a credit card PDTP) under“Payment Scheme B1” (for example, American Express), the domain of “BankB” also includes a “PDTP B2” (for example, a debit card PDTP) under“Payment Scheme B2” (for example, Visa).

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, a third party which is a notbank may also have an SSD on a DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the security hierarchy is arranged to be suitablefor operation with a TSM. In such a hierarchy, there is a lower part ofthe hierarchy (or sub-hierarchy) in which an SSD at the top of thesub-hierarchy is controlled by an issuer and one or more lower SSDsunder the top SSD each host a PDTP. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, each lower SSD may be for a different payment scheme (forexample, Mastercard, Visa, American Express). In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, each DTP/PDTP has one or more SSDs, each of the DTP/PDTPSSDs associated with at least one transaction application (eachtransaction application associated with the DTP/PDTP).

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the security hierarchy isarranged to be suitable for operation with a TSP. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, in such a hierarchy, there is a lower part ofthe hierarchy (or sub-hierarchy) in which an SSD at the top of thesub-hierarchy is controlled by a payment scheme (for example, VTS forVisa, MDES for Mastercard, or AETS for American Express) and one or morelower SSDs under the top SSD. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,each of the lower SSDs are for one or more issuers to host one or morePDTPs (wherein the SSDs may be owned by a TSP), wherein each PDTP is forthe same payment scheme. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,each DTP/PDTP has one or more SSDs, each of the DTP/PDTP SSDs associatedwith at least one transaction application (each transaction applicationassociated with the DTP/PDTP).

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the security hierarchy isarranged to be suitable for operation with both a TSM and a TSP. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the security hierarchy includessub-hierarchies structured for both TSM and TSP operations as describedabove.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the security hierarchy includes a lock SSD,which is operable and used to lock all SSDs under it. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the lock SSD can implement a cascade lock(which is operable to lock all directly and indirectly related SSDsunder the lock SSD), which is instigated by a single lock command andhas the advantage of not requiring each SSD in the hierarchy under thelock SSD to be individually locked.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the security hierarchy includes anapplication selection module SSD, being an SSD under which there are oneor more selection applications, including one or both of a PSE selectionapplication for contact digital transactions and a PPSE selectionapplication for contactless digital transactions.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the security hierarchy includesone or more Utility Security Domains (USDs), and it will be understoodthat the term USD is used in this specification to denote an SSD for acontainer. Each USD is used to host one or more containers for a paymentscheme. In some such embodiments of the present invention and/or in somesuch embodiments of its related technologies, there are three USDs, witha first USD hosting containers for Visa, a second USD hosting ELFs forMastercard, and a third USD hosting ELFs for American Express.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a security domain (under an ISD, a USD, oran SSD) in the security hierarchy is configured so that its key accessesonly the immediate security domain of the ISD, USD, or SSD. In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, the security domain is configured so that its keyaccesses all security domains under the immediate security domain.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a bank or issuing authority (for example abank or issuing authority which issues the DPD) will manage an ISD for aDTPU (including holding and operating with the ISD). In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, a third-party management agent (separate from abank or issuing authority which issues the DPD) may be appointed tomanage an ISD for a DTPU (including holding and operating with the ISD).In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, a bank or issuing authority anda third-party management agent may both manage an ISD for a DTPU.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTPU has one SSD as a domain for a bankor other type of issuing authority. In such embodiments of the presentinvention and/or in such embodiments of its related technologies, theDTPU has a plurality of SSDs as domains for a different bank or othertype of issuing authority. In some other embodiments of the presentinvention and/or in some other embodiments of its related technologies,at least one SSD of the one or plurality of SSDs hosts an at least onePDTP or at least one transaction application. In some other embodimentsof the present invention and/or in some other embodiments of its relatedtechnologies, though an SSD for a bank or other type of issuingauthority may be installed on the DTPU, that particular SSD may not hostany DTP/PDTP or transaction application.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, each DTP/PDTP is associated with a paymentscheme. In some embodiments of the present invention and/or in someembodiments of its related technologies, only one DTP/PDTP or onetransaction application for each payment scheme is allowed under aparticular SSD for a bank or other type of issuing authority. In someother embodiments of the present invention and/or in some otherembodiments of its related technologies, more than one DTP/PDTP or morethan one transaction application for each payment scheme is allowedunder a particular SSD for a bank or other type of issuing authority.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTPU is operable to have installedthereon a plurality of SSDs for different banks or other types ofissuing authority, but the DTPU is limited to allowing DTPs/PDTPs ortransaction applications hosted thereon to be associated with only onepayment scheme. In some other embodiments of the present inventionand/or in some other embodiments of its related technologies, the DTPUis limited to allowing DTPs/PDTPs or transaction applications hostedthereon to be associated with only a limited range of payment schemes.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTPU is operable to host a variety ofSSDs for different banks or other types of issuing authorities, avariety of PDTPs or transaction applications (sometimes for a variety ofpayment schemes) under those SSDs, wherein some of the PDTPs ortransaction applications have associated tokenized PDTPs or tokenizedtransaction applications and some of the PDTPs or transactionapplications do not have associated tokenized PDTPs or tokenizedtransaction applications, wherein some of the PDTPs or transactionapplications and/or some of the tokenized PDTPs or tokenized transactionapplications have an associated variety of transaction types and some ofthe PDTPs or transaction applications and/or some of the tokenized PDTPsor tokenized transaction applications do not have associated transactiontypes, wherein each PDTP or transaction application, tokenized PDTP ortokenized transaction application, and/or transaction type has one ormore associated transaction applications, and wherein the one or moreassociated transaction applications includes a single dualcontact/contactless interfaces transaction application, two transactionapplications each having either a contact or contactless interface, or amixture of dual interface and single interface transaction applications.In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTPU hosts some or all the varieties ofbank/issuing authority SSDs, PDTPs or transaction applications,tokenized PDTPs or tokenized transaction applications, transactiontypes, and transaction applications. In some embodiments of the presentinvention and/or in some embodiments of its related technologies, theDTPU hosts only a single bank/issuing authority SSD, with a single PDTPhaving one or more associated transaction applications or a singletransaction application.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU is operable to hostonly a limited range of the varieties of bank/issuing authority SSDs,personalities, tokenized PDTPs or tokenized transaction applications,transaction types, and transaction applications mentioned above.

Controlling Authority Security Domain (CASD)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU includes a domain called a ControllingAuthority Security Domain (CASD). A CASD is an additional securitydomain typically available in mobile devices applications on a UICC oreSE chips.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the CASD is for brokering trust between theDPD manager and other parties, such as an issuer or a NBIA.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DPD manager is operable for installingSSDs and instantiating transaction applications under those SSDs, inwhich case, the DPD manager has control of the cryptographic key foreach SSD it has installed. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the DPD manager is to pass control of one of the security domains toanother party (such as an issuer or a NBIA) so the other party canperform operations on the one or more transaction applications in thatsecurity domain, but it is not desired that the DPD manager provide thecryptographic key for the SSD directly to the other party. The CASD,which is controlled by a mutually trusted third party is operable toassist in performing a key rotation on the SSD, so that control of theSSD is passed to the other party, wherein the SSD is now controlled bythe cryptographic key of the other party, without this key havingpotentially been revealed to the DPD Manager. The other party is thenable to authenticate to the SSD with its cryptographic key so that itcan perform operations on the one or more transaction applications inthat security domain. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the otherparty can personalise the one or more transaction applications.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the CASD is provided to a“finance” approved chip (as typically used in credit and debit cards)where used as the DTPU. It will be appreciated that such “finance” chipshave not required a CASD previously as they were not provided with anyone or more of: new personalities, new DTPs/PDTPs, or new transactionapplications from a provisioning agent.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU is a UICC/eSE typechip wherein the DTC (or, more generally, the DPD where appropriate) isadapted to allow the UICC type chip to operate for both contact andcontactless transactions, and wherein the DTPU has a CASD installed.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the CASD is on a DTPU when issued by a chipmanufacturer or provider. In other embodiments of the present inventionand/or in other embodiments of its related technologies, a CASD may beprovided to the DTPU when it is remote from a provisioning agent or aprovisioning network.

Cryptographic Keys

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each security domain in a security hierarchy (forexample, including ISD or SSD security domains) has an associatedcryptographic key or keyset, sometimes referred to simply as a key orkeyset. If an operation is to be performed under a particular securitydomain a cryptographic key is required to generate a session key forencrypting a script or command so that the script or command is able toauthenticate to the SSD of the security domain. In embodiments of thepresent invention and/or in embodiments of its related technologies, oneor more security domains are configured so that its key accesses onlythe directly associated applications of the SSD or may be configured sothat its key accesses all security domains of SSDs under the immediateSSD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, in a security hierarchy there may be a number ofdifferent types of domain, including ISD, SSD, CASD and USD (all ofwhich are SSDs with a flag set to provide them with certain privileges).

Transaction Keys

In embodiments of the present invention and/or in embodiments of itsrelated technologies, in a transaction with a DTD security is requiredbetween the DTPU and the issuing bank, when engaging in a digitaltransaction with the DTD. In part, the security is provided by acryptographic key which is included in personalization of a DTP (tobecome a PDTP). The transaction key is typically owned by and known onlyto the issuer of the PDTP, which may be a bank or other suchinstitution.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a transaction session key is generated using thetransaction key for a PDTP (or for any of the transaction applicationsassociated with the PDTP) and other inputs for each digital transactionbetween the DPD (or the DTPU thereon) and a DTD.

Transaction Applications

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable for payment digitaltransactions. Transaction applications used for payment transactions maybe referred to as payment applications. In other embodiments of thepresent invention and/or in other embodiments of its relatedtechnologies, the DPD is operable for non-payment digital transactions,such as identification transactions, wherein the DPD may adopt thepersonality of a passport or a drivers license.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each transaction application has a transactionapplication identifier. In some embodiments of the present inventionand/or in some embodiments of its related technologies, the transactionapplication identifier is an Application ID (AID).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, for example, on JavaCards (or on DPDs usingJavaCard or JavaCard-like technology), transaction applications areimplemented on the DTPU as Java applets, and these are sometimesreferred to as transaction apps, payment apps, or simply as apps.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each transaction application is instantiated onthe DTPU and, when personalized, includes data, such as the PAN of thePDTP with which the transaction application is associated. In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, the PAN and other data of the personality arelocated in another application also associated with the personality. Inyet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the PAN and other data of thepersonality are located in another memory area of the DTPU to which thetransaction application has access to read the PAN. The other data ofthe personality may include expiry date of the personality, owner's name(cardholder's name) for the personality, and tokenized PANs of thepersonality.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD manager is operable to provide scripts tothe DTPU for instantiating transaction applications on the DTPU. In yetother embodiments of the present invention and/or in yet otherembodiments of its related technologies, other provisioning agents, suchas TSMs and TSPs are operable to provide scripts to the DTPU forpersonalizing transaction applications.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTP has one or more associated transactionapplications. In such embodiments of the present invention and/or insuch embodiments of its related technologies, the one or moretransaction applications are associated with the DTP (given that the oneor more transaction applications have not yet been personalized).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a PDTP has one or more associated transactionapplications. In such embodiments of the present invention and/or insuch embodiments of its related technologies, the one or moretransaction applications are associated with the PDTP afterpersonalization of the one or more transaction applications.

Transaction Interface

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a transaction application may have one or moreinterfaces, which are sometimes referred to as digital transactioninterfaces or digital transaction communication channels. In someembodiments of the present invention and/or in some embodiments of itsrelated technologies, a single transaction application is provided whichhas a dual interface for both contact and contactless transactions, andthus the same AID is supplied to the application selection module forthe PSE (contact selection application) for contact transactionapplication identification and for the PPSE (contactless selectionapplication) for contactless transaction application identification.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, two transaction applicationsare provided, one being a contact transaction application with a contacttransaction interface and the other being a contactless transactionapplication with a contactless transaction interface. In suchimplementations, a different AID is supplied to the applicationselection module for the PSE and for the PPSE.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, it is possible to provide botha dual contact/contactless interface transaction application and the twotransaction applications each having a single contact or contactlessinterface.

Digital Transaction

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a digital transaction occurs between the DTPU of aDPD and a DTD in a transaction network. In embodiments, the digitaltransaction of the DPD is governed by EMVCo standards for data transferand security between the DTPU and the DTD. Although, the presentinvention (and its related inventive technologies) contemplates digitaltransactions for both financial and non-financial purposes, the majorityof the description and embodiments are directed towards financialdigital transactions, sometimes referred to as payment transactions orsimply as payments.

Transaction Types

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each PDTP/personality may have one or moretransaction types (or digital transaction types) associated therewith.In some embodiments of the present invention and/or in some embodimentsof its related technologies, a transaction type may be an account, andif a PDTP/personality has two associated transaction types, onetransaction type could be an account for transactions in USD currencyand the other transaction type could be an account in Euro currency. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, a card user is able selectwhich transaction type will be used for the PDTP/personality during adigital transaction and can select, for example, among differentcurrency accounts linked to the same PDTP/personality (or linked to thesame primary identifier or PAN). In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,different transaction types associated with a single PDTP/personalitymay also include transaction types for the same account, but withdifferent information registered for an account record or statement.

In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, each transaction type isassociated with one transaction application of a PDTP. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, each transaction application associated with atransaction type will be personalized with data such that the associatedtransaction will operate in a digital transaction to associate thatdigital transaction with the transaction type.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, examples of different transaction types which maybe associated with a single PDTP/personality include:

-   -   Two or more different currency accounts;    -   Multiple accounts for different family members (partners,        children, siblings, parents, etc);    -   Multiple accounts for different spending categories in a        business (or could be the same account with different        registrations in an account statement);    -   Business/personal spending (could be the same account, but        registered differently on an account statement);    -   Different transaction types for multiple loyalty reward schemes        (perhaps each linked to the same account).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a card user (or DPD user) is able selectwhich transaction type will be used for the PDTP/personality during adigital transaction and can select, for example, among differentcurrency accounts linked to the same personality (or linked to the sameprimary identifier or PAN for each of the transaction applications inthe associated PDTP).

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DPD is operable toautomatically select which transaction type is used for the currentoperating personality of the DPD. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the DPD user programs the DPD to always use a US currencyaccount for whichever personality is selected to be the operablepersonality of the DPD, provided a US currency account is an availabletransaction type option for the selected operating personality. Theprogramming for the automatic transaction type selection could beeffected through the DPD user interface or through a DAD user interfacewhen the DAD is linked to the DPD for communication therebetween. In afurther usage example for such embodiments, the DPD user may betravelling in Europe and could program the DPD to use Euro accounttransaction types (or payment types), where such transaction types areavailable for the selected personality. In some such embodiments and inscenarios where a particular currency account transaction type for apersonality is preferred, but isn't available, the DPD is operable todefault to a selected default transaction type.

Digital Transaction Package (DTP)/Personalized Digital TransactionPackage (PDTP)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a Digital Transaction Package (DTP) is a groupingof one or more transaction applications, each transaction applicationhaving either or both of a contact and contactless interface forengaging in digital transactions with DTDs in a transaction network.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTP is instantiated on a DTPU using a container,and extradited to an SSD elsewhere in the security hierarchy of theDTPU. Once extradited to its target SSD, the DTP is then personalized tobecome a Personalized DTP (PDTP).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the SSD to which the DTP is extradited isinstalled on the DTPU in a selected place in the security hierarchy inadvance of creating and extraditing the DTP. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the SSD is created by one or more scripts provided to theDTPU by the DPD manager.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTP is created on the DTPU by reference to acontainer for a particular payment scheme, which provides a library offunctions for the one or more transaction applications associated withthe DTP to operate on the DTPU for transactions. For example, a DTP fora Visa credit card is created on the DTPU by sending a script ofcommands to an ELF (container) for the Visa credit card, wherein thecontainer creates the one or more transaction applications associatedwith the DTP in a part of the memory of the DTPU. At this stage, the DTPhas not been personalized and so its one or more associated transactionapplications do not have any one or more of an associated primaryidentifier (PAN), an expiry date, a transaction key and otherpersonalization data, but the DTP has only the one or more associatedtransaction applications and transaction interfaces, none of which havebeen personalized.

In this specification, unless otherwise indicated or where the contextrequires or benefits, a DTP includes only the transaction applicationsand/or associated payment interfaces. A DTP does not includepersonalization data associated with the specific card. For example, aDTP for a credit card does not include the PAN, cardholder name, expirydate and other personalization data. A DTP may be personalized to becomea Personalized Digital Transaction Package (PDTP), in which casepersonalization data is provided to or with the DTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, personalization data is written to the DTP tobecome a PDTP. In some embodiments, personalization data is provided tothe DTPU on which a DTP is installed in the form of a script so that theDTPU can transform the DTP to a PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTP/PDTP is operable for both contact andcontactless transactions (or has one or more associated transactionapplications operable for both contact and/or contactless transactions).In other embodiments, a DTP/PDTP may be operable only for one of eithercontact or contactless transactions (or has one or more associatedtransaction applications operable for only contact or contactlesstransactions).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some DTP/PDTPs are suitable for paymenttransactions, and some for non-payment transactions, such as securestorage and presentation (or secure presentation) personal ID, ageverification and other non-payment functions.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the scripts to create the DTP/PDTP may also beprovided to the DPD with other DPD files and data (including metadata),including:

-   -   file(s) to provide a logo or mark for the payment scheme        associated with the DTP/PDTP to be displayed on the graphical        user interface of the DPD;    -   file(s) containing one or more AIDs associated with the one or        more transaction applications which are provided to the DTPU for        updating the application selection module, including the PSE and        PPSE selection applications, when changing the operating        personality of the DTPU (or the DPD) to that associated with the        PDTP. In alternative embodiments, the DTP/PDTP can be provided        along with one or more modified application selection module        file including AIDs for the one or more transaction applications        which are provided with the DTP/PDTP, wherein the modified        application selection module file are installed onto the DTPU to        overwrite or substitute for the previously installed modified        application selection module files;    -   file(s) containing the PAN of the PDTP for display on the        graphical user interface when the PDTP is the operating PDTP for        the DTPU, associated with the operating personality of the DPD        (sometimes referred to as metadata).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each PDTP is an aspect of a personality, the PDTPbeing installed on the DTPU, and other aspects of a personality are themetadata associated with the PDTP. In embodiments of the presentinvention and/or in embodiments of its related technologies, metadataassociated with the PDTP and constituting the personality is stored byany one or more of: the DPD, the DAD, and the DPD manager. Inembodiments of the present invention and/or in embodiments of itsrelated technologies, the metadata associated with the PDTP andconstituting the personality is stored by any one or more of: a TSM, aTSP, and an issuer.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the DTPU may be provided with a containerfor a new payment scheme if that payment scheme does not have acontainer on the DTPU, or if a replacement container is required for anexisting payment scheme on the DPTU. If loading a new payment schemecontainer onto the DPTU, a new USD security domain is created and thenew container loaded (or installed) therein. In embodiments, thescript(s) to create the USD may be provided by one party, such as theDPD manager, and the script(s) to create the container under that USDmay be provided by the payment scheme or the DPPD manager. In some suchembodiments, a key rotation for the USD may be required before thecontainer is installed in the USD by the payment scheme.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, each DTP/PDTP is associated with a separatesecurity domain. In such embodiments, all commands (as APDUs) for orassociated with the DTP/PDTP must be authenticated to the securitydomain of the DTP/PDTP. Typically, the security domain is an SSD. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the SSD of the DTP/PDTP canhost contact and contactless instances (applications) together or keepthem in separate sub-security domains (sub-SSDs).

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a security domain associated with aDTP/PDTP (as associated with a personality of the DPD) can bere-personalized by substituting a keyset (a set of cryptographic keys,for example, an SCP02 keyset for OTA communications, or SCP80/81 for OTIcommunications) for that security domain with a new keyset. In suchembodiments, and particularly where the instances (applications) are ina separate sub-domain, changing the keyset will not affect the ELFs(containers) or applications/instances associated to that securitydomain.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, a DTP/PDTP has a plurality of associatedtransaction applications wherein one or more of the plurality oftransaction applications are for a first transaction type, and one ormore of the plurality of transaction applications are for a secondtransaction type. In such embodiments, the first transaction type is fora first account associated with the PAN of the PDTP and the secondtransaction type is for a second account associated with the PAN of thePDTP. In embodiments, in personalization, the one or more transactionapplications associated with the first transaction type are personalizedwith data including a first sequence number and the one or moretransaction applications associated with the second transaction type arepersonalized with data including a second sequence number.

In an example usage of such embodiments, a DPD user may choose the PDTPwith different transaction type transaction applications from amongst anumber of selectable PDTPs installed on the DTPU of the DPD, the DPDuser may then choose an account for that PDTP from amongst a number ofselectable accounts for that PDTP, the MCU of the DPD requests thescripts from the OSE to lock all PDTPs (or lock all the transactionapplications associated therewith) in the DTPU (by targeting the LockSSD). The MCU then requests an unlock script targeted only at the one ormore transaction applications in the selected PDTP which are associatedwith the selected transaction type (selected account), the MCU send theunlock script to the DPTU for execution. In some such embodiments, theunlock script targets the application selection module (by targeting oneof the PSE or PPSE selection applications in the application selectionmodule) to first update the registry of the application selection moduleto include the AID(s) of the one or more transaction applications to beunlocked, the application selection module then targets the one or moretransaction applications to be unlocked (in some circumstances, the SSDof the targeted transaction applications can remain locked while thetransaction applications are targeted to be locked or unlocked). The DPDcan then be presented to a DTD for a digital transaction, either bycontact (dipping) or contactless (waving or tapping). The applicationselection module will provide the AIDs (in a candidate list) to the DTD,and the unlocked transaction applications will be available for thedigital transaction with the DTD (the locking of non-selectedtransaction applications being important if the DTD engages in directselection, rather than using the PSE for a contact transaction). Duringsuch a digital transaction, the transaction application provides the PANand the sequence number (and other information) to the DTD, wherein theprovided sequence number allows the issuer (say, a bank) to target thedesired associated one of the one or more accounts for that PAN fordebit.

Personality

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a personality includes a PDTP (hosted on theDTPU), along with metadata associated with the PDTP. In some embodimentsof the present invention and/or in some embodiments of its relatedtechnologies, the metadata is hosted by any one or more of: the DPD (forexample, on the MCU), the DAD, and the DPD manager.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a personality or digital transaction personalityincludes aspects of the external appearance and operation of a PDTP (asobserved by a user of the PDTP). In embodiments of the present inventionand/or in embodiments of its related technologies, the personality isalso associated with a cardholder name, expiry date, a CVV and variousother data, however, in embodiments, the primary association of eachpersonality is its PAN or its unique identifier (for a PAN, each issuerhas a different combination of the first six PAN digits and eachcardholders account number (the remainder of the PAN digits) isdifferent). For payment transaction personalities, such as credit ordebit cards, the PAN is always numeric. Other types of transaction cardsor documents, such as passports, drivers licenses, and proof of agecards may have unique identifiers which are alphanumeric.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTPU may have one or more personalities (PDTPs),wherein each personality is associated with at least a PAN or anotherunique identifier.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each personality (or associated DTP/PDTP) isassociated with one or more transaction applications.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD can have more than one active personalityat the same time. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the DPD hasan active financial personality (for example, a credit card), and anactive non-financial personality (such as a drivers license). These twodifferent types of personality have different transaction applicationson the DTPU associated with the personalities, and the differenttransaction applications are operable with different types of DTD.Accordingly, the personalities, while both being active on the DPD (andthe DTPU) will not have a conflict when used at the different DTDs. Insome other such embodiments of the present invention and/or in someother such embodiments of its related technologies, there can be twofinancial personalities active on the DPD at the same time, however, onepersonality will be restricted to contact only transactions, and theother personality will be restricted to contactless only transactions,otherwise the two financial personalities would cause conflicts in theDTD behaviour.

Tokenized PDTP

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each PDTP may be associated with one or moretokenized transaction applications, wherein the primary identifier foreach associated transaction application has a different tokenized value(for finance PDTPs the primary identifier is a PAN). Where token PDTPsare used, for enhanced security, the graphical display of the DPD maydisplay only the PAN for the token PDTP, but not display the primary PANof that PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, when personalizing a DTP by personalizing each ofthe one or more transaction applications associated with the DTP, eachof the one or more transaction applications is personalized with adifferent tokenized identifier associated with the one primaryidentifier.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a tokenized PDTP with associated tokenizedtransaction applications may provide for enhanced security as the actualprimary identifier (or PAN) of the PDTP is not revealed for atransaction and the tokenized primary identifier is used instead. Insome embodiments of the present invention and/or in some embodiments ofits related technologies, the graphical display of the DPD (whereoptionally having a graphical display) may display only the tokenizedprimary identifier (or PAN) for the unlocked tokenized transactionapplication, but not display the primary identifier (or primary PAN) ofthat unlocked transaction application.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, one of the one or more tokenized transactionapplications of a tokenized PDTP associated with a personality is usedfor a digital transaction instead of the non-tokenized transactionapplication.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where one or more tokenized transactionapplications are available (each tokenized transaction applicationassociated with one of one or more tokenized PDTPs and each tokenizedPDTP associated with a personality or tokenized personality), the DPD isoperable for a DPD user (sometimes referred to as a DPD-holder, DTC useror cardholder) to select from tokenized transaction applications and anon-tokenized transaction applications for use in a digital transaction.In further embodiments of the present invention and/or in furtherembodiments of its related technologies, the DPD is operable for a DPDuser to select one of a plurality of tokenized transaction applicationsfor use in a digital transaction.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the DPD is configured to use atokenized transaction application of there is at least one availabletokenized transaction application for an active PDTP associated with anoperating personality of the DPD. In further embodiments of the presentinvention and/or in further embodiments of its related technologies, ifthere is a range of available tokenized transaction applications for anactive PDTP associated with an operating personality of the DPD, the DPDis configured to select automatically one of the tokenized transactionapplications. In some such embodiments of the present invention and/orin some such embodiments of its related technologies, the automaticselection is random or pseudo-random from the range. In other suchembodiments, the selection is based on a pre-set order of the tokenizedtransaction applications in the range.

Although a Token Service Provider (TSP) may be used in some embodimentsto provision one or more DTPs/PDTPs (each PDTP associated with apersonality of the DPD) to the DTPU, it should be noted that suchprovisioning may use only a single PAN for each PDTP (that is, a singlePAN for personalizing the one or more transaction application associatedwith the DTP/PDTP) as provided by the TSP, rather than a plurality oftokenized PANs related to a primary PAN of a PDTP.

Application Selection Module and Selection Applications

When a DPD is presented to a DTD for a digital transaction, there mustbe a determination as to which one of possibly multiple PDTPs and/orwhich of the transaction applications associated with the one PDTPis/are to be used for effecting the payment transaction. Different DTDsin different parts of the world will likely operate with differentpayment networks (transaction providers), and so it may be that a DTPUhaving several installed PDTPs with one or more transaction applicationsassociated with each PDTP can effect the transaction with only a subsetof the several transaction applications. The process for selection ofthe one or more payment applications on a DPD which are able to effect apayment transaction with payment networks available to the DTD is calledapplication selection. Each transaction provider is an agent remote fromthe DTD and is able to cause required actions for the transaction to beeffected. For payment transactions between a payment DTC and a paymentDTD, each transaction provider operable with the DTD is a paymentnetwork and is able to authorize a payment from an account of thecardholder to an account of the owner of the DTD.

Application selection can occur in one of three ways: direct selection,selection through the Payment System Environment (PSE), or selectionthrough the Proximity Payment System Environment (PPSE). Directselection and PSE are employed for contact digital transactions with aDTD. PPSE is employed for contactless digital transactions.

In direct selection, the DTD directly interrogates the SE/EMV+GP chip tofind the unique AIDs for the payment applications. The DTD will thendetermine which, if any, of the available applications it is capable ofoperating to effect a payment transaction with payment networksavailable to the DTD. This process is liable to have some uncertaintiesas DTDs operate in different ways. The DTD may simply choose the firstAID with which it can operate or may look through all the available AIDson the SE/EMV+GP chip. The DTC is unable to control the direct selectionprocess.

PSE operates by means of an application which has an associated uniqueAID and may be referred to as a selection application, a PSE selectionapplication, or a PSE application. The PSE method is optional for both aDTC and DTD for a contact transaction, with direct selection being afall-back option. Depending on the region, the network, setup andconfiguration or the supplier of the DTD either a PSE or a directselection method is used. For a standard credit or debit card which hasa single personality, the PSE application selection method operates asfollows:

-   -   the DTD selects the PSE;    -   the File Control Information (FCI) returned by the PSE contains        the AID of the Payment System Directory;    -   the DTD selects the Payment System Directory ADF;    -   for each record in the ADF the DTD reads the payment application        AID;    -   if the AID matches an AID (or, more likely, an RID) on the DTD's        list of payment applications with which it is capable of        conducting a transaction, the AID is entered onto the candidate        list created by the DTD;    -   after the last record is processed the DTD selects a payment        application AID based on priorities kept by the PSE;    -   the DTD then processes the payment transaction using the        selected payment application.

For PSE, if the AID on the candidate list (sometimes referred to as aPSE list) does not match an AID with which the DTD is configured tooperate, the DTD is able to revert to direct selection.

PPSE also operates by means of an application with a unique AID. ThePPSE method is mandatory for both the DTC and DTD for contactlesstransactions. Unlike PSE, the PPSE application returns a list ofavailable payment application AIDs in its FCI. For a standard credit ordebit card having a single personality, the PPSE application selectionmethod operates as follows:

-   -   the DTD selects the PPSE;    -   the PPSE FCI returned has a list of AIDs and meta information        (for example, payment application priority) for selection by the        DTD;    -   if the AID matches an AID on the DTD's list of payment        applications with which it is capable of conducting a        transaction, the AID is entered onto the candidate list created        by the DTD;    -   after the last record is processed the DTD selects a payment        application AID based on priorities in the PPSE FCI;    -   the DTD then processes the payment transaction using the        selected payment application.

The PSE application and PPSE application on the SE/EMV+GP chip arestatic in that the list of AIDs for these selection applications(typically populated during personalization of a traditional paymentcard) is not changed for the operable life of the DTC. Further,traditional PSE and PPSE applications are adapted to function with aSE/EMV+GP chip having a single personality installed thereon.Implementation of PPSE on mobile payment devices, such as smartphones(on an eSE), is different from implementation of PPSE for SE/EMV+GPs onDTCs. On a mobile device PPSE dynamically accommodates for changes inthe personalities on the device, whereas PPSE on a DTC does not need toaccommodate such change as, with traditional DTCs, the personalitieshave remained fixed after issuance of the DTC to a cardholder.

In some of the selection application embodiments discussed below, theone or more transaction application identifiers set in the one or moreselection applications will be understood to be identifiers of one ormore unlocked transaction applications (associated with an active (oractivated) PDTP of the DTPU, which is associated with a personality ofthe DPD selected to be the operable personality of the DPD). In someother embodiments selection application embodiments discussed below, theone or more transaction application identifiers set in the one or moreselection applications will be understood to be identifiers of one ormore unlocked tokenized transaction applications (associated with anactive (or activated) tokenized PDTP of the DTPU, which is associatedwith a personality (or tokenized personality) of the DPD selected to bethe operable personality of the DPD). In some other embodimentsselection application embodiments discussed below, the one or moretransaction application identifiers set in the one or more selectionapplications will be understood to be identifiers of one or moretransaction applications associated with a selected transaction typeitself (associated with an active (or activated) PDTP of the DTPU, whichis associated with a personality of the DPD selected to be the operablepersonality of the DPD). In some other application selection moduleembodiments discussed below, the one or more transaction applicationidentifiers set in the one or more selection applications will beunderstood to be identifiers of one or more tokenized transactionapplications associated with a selected transaction type itself(associated with an active (or activated) tokenized PDTP of the DTPU,which is associated with a personality (or tokenized personality) of theDPD selected to be the operable personality of the DPD).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU includes an application selection module,wherein the application selection module includes one or both of aselection application for contact digital transactions (PSE application)and a selection application for contactless digital transactions (PPSEapplication).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the application selection module is operable to beset with one or more transaction application identifiers. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the transaction application identifier is anapplication ID (AID).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, when a personality is selected to be the activepersonality of the DPD, the application selection module is set with oneor more transaction application identifiers associated with thetransaction applications of the PDTP associated with the personalityselected to be the active personality.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the PDTP of a personality has a single associatedtransaction application with dual contact/contactless interfaces, andthe single associated transaction application has an identifier, whichin some embodiments is an AID. In such embodiments of the presentinvention and/or in such embodiments of its related technologies, thePSE and the PPSE selection applications are each set with the sameidentifier.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a PDTP has two associated transactionapplications, one with a contact interface and the other with acontactless interface, and the associated transaction applications havedifferent transaction application identifiers from each other. In suchembodiments of the present invention and/or in such embodiments of itsrelated technologies, the PSE selection application is set with theidentifier of the transaction application having the contact interfaceand the PPSE selection application is set with the identifier of thetransaction application having the contactless interface.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where a tokenized PDTP includesone or more tokenized transaction applications, and where one of thetokenized transaction applications is selected to be the unlockedtransaction application when the PDTP is selected to be the active PDTP(or to be one of the active PDTPs) on the DTPU, and where the unlockedtransaction application is dual interface for both contact andcontactless transactions, the transaction application identifier (AID)for the unlocked transaction application is provided to the applicationselection module to set both the contact selection application and thecontactless selection application with the same transaction applicationidentifier.

In yet other embodiments of the present invention and/or in otherembodiments of its related technologies, where a tokenized PDTP includestwo or more tokenized transaction applications, and where two of thetokenized transaction applications (each having the same tokenized PAN)are selected to be the unlocked transaction applications when the PDTPis selected to be the active PDTP (or to be one of the active PDTPs) onthe DTPU, and where the unlocked transaction applications each have oneof a contact interface and a contactless interface, the transactionapplication identifiers (AIDs) for each of the unlocked transactionapplication is provided to the application selection module to set eachof the contact selection application and the contactless selectionapplication with the respective transaction application identifier forthe two unlocked tokenized transaction applications.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where a PDTP includes two ormore transaction type transaction applications, and where one of thetransaction type transaction applications is selected to be the unlockedtransaction application when the PDTP is selected to be the active PDTP(or to be one of the active PDTPs) on the DTPU, and where the unlockedtransaction application is dual interface for both contact andcontactless transactions, the transaction application identifier (AID)for the unlocked transaction application is provided to the applicationselection module to set both the contact selection application and thecontactless selection application with the same transaction applicationidentifier.

In yet other embodiments of the present invention and/or in otherembodiments of its related technologies, where a PDTP includes two ormore transaction type transaction applications, and where two of thetransaction applications (each having the same transaction typeidentifier) are selected to be the unlocked transaction applicationswhen the PDTP is selected to be the active PDTP (or to be one of theactive PDTPs) on the DTPU, and where the unlocked transactionapplications each have one of a contact interface and a contactlessinterface, the transaction application identifiers (AIDs) for each ofthe unlocked transaction application is provided to the applicationselection module to set each of the contact selection application andthe contactless selection application with the respective transactionapplication identifier for the two unlocked tokenized transactionapplications.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU hosts a variety ofSSDs for different banks or other types of issuing authorities, avariety of PDTPs (sometimes for a variety of payment schemes) underthose SSDs, wherein some of the PDTPs have associated tokenizedtransaction applications (tokenized PDTPs) and some of the PDTPs do nothave associated tokenized transaction applications, wherein some of thePDTPs and/or some of the tokenized PDTPs have an associated variety oftransaction types and some of the PDTPs and/or some of the tokenizedPDTPs do not have associated transaction types, wherein each PDTP,tokenized PDTP, and/or transaction type PDTP has one or more associatedtransaction applications, and wherein the one or more associatedtransaction applications include dual contact/contactless interfacetransaction application, two transaction applications each having eithera contact or contactless interface, or a mixture of dual interface andsingle interface transaction applications. In such embodiments, how thetransaction application identifier(s) for the one or more selectionapplications are set will depend on whether the selected PDTP, tokenizedPDTP or transaction type PDTP is associated with a single dual interfacetransaction application or two single interface transactionapplications.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the one or more selectionapplications are set with an identifier by placing into a registry ofthe application selection module the transaction applicationidentifier(s) of one or more transaction applications associated with aselected operating PDTP, tokenized PDTP, and/or transaction type PDTP(associated with the operating personality of the DPD). In some suchembodiments, at least one of the selection applications is operable toautomatically set its transaction application identifier when thetransaction application identifier is placed into the applicationselection module registry. In other embodiments of the present inventionand/or in other embodiments of its related technologies, at least one ofthe selection applications has its identifier set when the identifier isplaced into the registry and the selection application is provided acommand to retrieve the identifier from the registry. In otherembodiments of the present invention and/or in other embodiments of itsrelated technologies, the command is provided as either a script or ancommand delivered from the MCU.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the PPSE selection applicationautomatically sets its transaction application identifier when thetransaction application identifier is placed in the registry and thenPSE selection application has its transaction application identifier setwhen the transaction application identifier is placed into the registryand the PSE selection application is provided a command to retrieve thetransaction application identifier from the registry.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the one or more selectionapplications are set with an transaction application identifier bypassing the identifier(s) as a parameter to the one or more selectionapplications wherein the one or more selection applications are eachoperable to re-set themselves with the passed transaction applicationidentifier parameter.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where there is a plurality oftransaction applications each of the same sort (dual interface contactand contactless, or single interface contact or contactless) associatedwith a personality, tokenized PDTP, and/or a transaction type PDTP, andthe transaction applications of the same sort each have a differenttransaction application identifier (AID in some embodiments) with apriority indicator, the one or more selection applications are operableto be set with the plurality of transaction application identifiers ofthe transaction applications of the same sort and to be set with therelated priority indicators.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the one or more selection applications are calledduring a digital transaction and the transaction application identifierset in each of the one or more selection applications is used to build acandidate list of transaction application identifiers. The candidatelist is used by a DTD in a digital transaction to determine which of thetransaction applications hosted on the DTPU the DTD is able to operatewith in order to effect the digital transaction. In embodiments where aselection application provides multiple transaction applicationidentifiers, each for a different transaction application, the candidatelist may include priority indicators provided by the selectionapplication, which assist the DTD in determining which of thetransaction applications identified in the candidate list is preferredto be called by the DTD for a digital transaction.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTD is operable to build acandidate list of transaction application identifiers (AIDs in someembodiments), which are passed to a DTD during a digital transaction sothat the DTD is able to determine the identity of an unlockedtransaction application on the DPD with which it is able to perform adigital transaction. In some such embodiments, the candidate list isbuilt when a DPD user selects a new personality (including selection ofa tokenized transaction application associated with the PDTP of thepersonality, and/or selection of a transaction application having aparticular transaction type) to be the operating personality of the DPD.In some other such embodiments, the candidate list is built by the DTDwhen a DPD is presented to a DTD for a digital transaction.

It will be understood that a digital transaction is either a contacttransaction or a contactless transaction, but never both, so that eithera PSE selection application is called during the digital transaction toprovide the identifiers of contact interface transaction applications,or a PPSE selection application is called during the digital transactionto provide the identifiers of contactless interface transactionapplications. In other embodiments of the present invention and/or inother embodiments of its related technologies, the DPD is operable forQR code payments, by display of a QR code by the DPD, the QR coderepresenting the one or more unlocked transaction applications (orrepresenting the PDTP/personality associated with the one or moreunlocked transaction applications).

Containers

In embodiments of the present invention and/or in embodiments of itsrelated technologies, Elementary Load Files (ELFs) or packages arereferred to as containers. It will be recognised that the terminology isinterchangeable and should be applied as required for the technologyused for implementing embodiments of the present invention. For example,if the embodiment is implemented on a JavaCard (or using JavaCard-liketechnology), the DTPU hosts packages for providing basic or commonfunctionality to transaction applications instantiated under a paymentscheme. In this specification, the term container is intended to be ageneralised reference to ELFs and packages.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a container for the present invention isimplemented on the DTPU of a physical card (a DTC) or on a DPD, and maybe operable with DTPs/PDTPs (see below) for both contact and contactlessdigital transactions.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each container (for example, one or more ELFscomprising the container) is associated with a payment scheme. In thesecurity hierarchy, each container is installed (or hosted) under anassociated USD. For example, a USD for the Visa payment scheme hosts oneor more ELFs for creating Visa DTPs on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a container is used to create the DTP, which isthen extradited from being under the USD of the container to an SSDelsewhere in the security hierarchy.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each USD can be locked or unlocked. Locking orunlocking of a container USD (or SSD) renders the container thereunder,respectively, as being active (unlocked) or inactive (locked). In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, it is possible to limit whichpayment schemes are operable on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, for example, a payment scheme, say the Visapayment scheme, may desire that the DPD is not used for hosting anyDTP/PDTPs of other payment schemes, such as Mastercard and AmericanExpress. The Visa payment scheme organisation may request for all USDsfor payment schemes apart from the USD for the Visa payment scheme to belocked. The DPD will then only be operable to create and installDTPs/PDTPs for the Visa payment scheme. It is understood that, inpractice, which DTPs/PDTPs are created and installed on a DTPU can becontrolled by the provisioning network by simply not providing means forcreating and installing DTPs/PDTPs from payment schemes other than froma desired (or from a number of desired) payment schemes. However,allowing for locking/unlocking of container USDs provides an extraassurance that the DPD can be controlled to only allow creation andinstallation of DTPs/PDTPs from one or more desired payment schemes.Although the above description of containers focuses on those forpayment schemes, it will be appreciated that other types of containercan be hosted on a DTPU, including containers for creation and hostinglibrary functions for ID cards, passports, and other non-financialelectronic documents.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DTPU includes at least some containers (ELFs)installed which are operable to instantiate transaction applications forfurther provisioning (personalization) by scripts provided by both a TSPand a TSM.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU includes at least somecontainers which are operable to instantiate transaction applicationsfor further provisioning (personalization) by scripts provided by a TSMonly.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DTPU includes at least somecontainers which are operable to instantiate transaction applicationsfor further provisioning (personalization) by scripts provided by a TSPonly.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a container is operable to instantiatetransaction applications for further provisioning (personalization) byscripts provided by a TSM only, the DTPU is operable to have anothercontainer installed which is operable to instantiate transactionapplications for further provisioning (personalization) by scriptsprovided by a TSP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a container is operable to instantiatetransaction applications for further provisioning (personalization) byscripts provided by a TSP only, the DTPU is operable to have anothercontainer installed which is operable to instantiate transactionapplications for further provisioning (personalization) by scriptsprovided by a TSM.

Digital Objects

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning network is operable to senddigital objects to the DPD and the DAD, to the DPD via the DAD, and tothe DAD via the DPD. In embodiments of the present invention and/or inembodiments of its related technologies, the digital objects includecommand, scripts, script templates, metadata, firmware, and other fileswhich are used on the DPD and/or the DAD.

Scripts and Commands

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a command is sent to the DTPU to effect an actionon the DTPU. A command, in various circumstances, may be referred to asan APDU. In other circumstances, a command may be broken up into APDUs.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, in a GP standards compliant DTPU all commands sentto a DTPU are in the form of one or more scripts.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some scripts require encryption with a session keyderived from a cryptographic key for an SSD to be authenticated to anSSD for authorizing a command to the security domain of the SSD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some scripts do not require encryption.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some scripts require encryption, the DPD isoperable to store and operate with template scripts, wherein thetemplate script requires one or more parameters, and when the one ormore parameters are written into the template script, the script isencrypted with a session key derived from a cryptographic key and acounter.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, some scripts require encryption, scripts includecommand scripts and response scripts, wherein a response script isgenerated by the DTPU when it has executed a command script, and theresponse script is sent by the DTPU via the DPD and back to the relevantprovisioning agent.

Metadata and Other On-DPD Files

In embodiments of the present invention and/or in embodiments of itsrelated technologies, each personality is associated with a single PDTPon the DPTU. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, each personality isalso associated with metadata related to the PDTP on the DTPU, whereinthe metadata is recorded in registries on any one or more of: the DPD(for example, in the MCU), the DAD, the DPD manager, and elsewhere. Inthis regard, a personality includes the PDTP and its associatedmetadata.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is provided with files (sometimes referredto as DPD files and data) for operations of selected components of theDPD, wherein the files and/or data are not associated with (or notdirectly associated with) data and operations on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD files and data includes firmwareinstructions for operations of components such as DPD buttons, the DPDcommunications module, the DPD graphical display, and other such filesand/or data.

Provisioning

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning network is operable to issue oneor more provisioning entities for providing, to the DPD, provisioningdata associated with at least one DTP/PDTP. In some embodiments of thepresent invention and/or in some embodiments of its relatedtechnologies, the one or more provisioning entities include data,digital objects, software or signalling entities generated by, orreceived by, the at least one provisioning agent for establishingcommunication sessions.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, provisioning includes providing from theprovisioning network and/or the provisioning infrastructure to the DTPUthe one or more provisioning entities, including data, digital objects,software or signalling entities generated by the at least oneprovisioning agent. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies,provisioning includes one or more responses from the DTPU back to theprovisioning network, the responses including one or more of data anddigital objects.

In some further embodiments of the present invention and/or in somefurther embodiments of its related technologies, provisioning includesproviding from the provisioning network and/or the provisioninginfrastructure to the MCU or some other component of the DPD external tothe DTPU the one or more provisioning entities, including data, digitalobjects, software or signalling entities generated by the at least oneprovisioning agent. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies,provisioning includes one or more responses from the MCU or some othercomponent of the DPD external to the DTPU back to the provisioningnetwork, the responses including one or more of data and digitalobjects.

Provisioning Data (for the DTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning data includes data associatedwith at least one DTP. In embodiments of the present invention and/or inembodiments of its related technologies, the data associated with atleast one DTP includes scripts and/or commands for installing one ormore SSDs on the DTPU. In embodiments of the present invention and/or inembodiments of its related technologies, the data associated with theDTP includes scripts and/or commands for instantiating one or moretransaction applications each under one of the one or more SSDs. Inembodiments of the present invention and/or in embodiments of itsrelated technologies, the data associated with at least one DTP includesscripts and/or commands for personalization to render the DTP a PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DTP is installed or created on the DTPU byproviding one or more scripts and/or commands to the DTPU from theprovisioning network (or from a least one provisioning agent in theprovisioning network) to instruct the DTPU to create or install the DTP.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the script instructs the DTPUto create the DTP with reference to a container (for example, an ELF)associated with a payment scheme (for example, Visa, Mastercard,American Express). In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the atleast one provisioning agent is the DPD manager.

In some other embodiments of the present invention and/or in some otherembodiments of its related technologies, the provisioning data includesscripts and/or commands for instantiating an application selectionmodule on the DTPU, including one or both of a selection application fora PSE and a selection application for a PPSE, each of the PSE and PPSEselection applications operable to provide to a DTD one or moretransaction application identifiers associated with the one or moretransaction applications associated with the at least one DTP/PDTP. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the provisioning data forinstantiating the application selection module is provided from the DPDmanager.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the data associated with at least one DTP/PDTPincludes one or both of a manifest for a PSE selection application and aPPSE selection application, or a manifest for the application selectionmodule, each manifest for modifying its respective selection applicationto include one or more transaction application identifiers associatedwith the at least one DTP/PDTP. In such embodiments of the presentinvention and/or in such embodiments of its related technologies, themanifest for a PSE selection application and a PPSE selectionapplication are for installation or storage on the MCU, the OSE or someother component of the DPD external to the DTPU, the MCU, the OSE orother component being operable to modify PSE and PPSE selectionapplications on the DPTU with data from each or both manifests. Inembodiments of the present invention and/or in embodiments of itsrelated technologies, the at least one manifest is provided in the formof one or more scripts and/or commands. In embodiments of the presentinvention and/or in embodiments of its related technologies, the atleast one manifest is provided in the form of one or more templatescripts and/or template commands. In embodiments of the presentinvention and/or in embodiments of its related technologies, the one ormore transaction application identifiers (AIDs) associated with the atleast one DTP/PDTP are in the metadata (for example the metadata on theMCU), and are provided to the PSE selection application and the PPSEselection application, or provided to the application selection modulewhen the personality (and/or tokenized transaction application, and/ortransaction type) is selected to be the operational personality of theDPD.

In yet some other embodiments of the present invention and/or in yetsome other embodiments of its related technologies, the data associatedwith at least one DTP includes personalization data, including one ormore commands and/or scripts, for the at least one DTP to bepersonalized on the DTPU, thus becoming a PDTP. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the personalization data is provided by a TSM and/or a TSPin the provisioning network. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the personalization data is provided to the TSM and/or the TSP andconverted by the TSM and/or TSP into one or more scripts and/orcommands. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the personalizationscripts and/or commands are provided from the TSM and/or the TSP to theDPD manager for delivery to the DPD.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the data associated with at least one DTP/PDTPincludes a container for providing functions for the at least oneDTP/PDTP, the container for installation on the DTPU, wherein thecontainer is associated with the payment scheme for the DTP/PDTP. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the container is operable toinstantiate one or more transaction applications for the DTP/PDTP forcontact and contactless payments to provide functionality required forthe DTP/PDTP which is operable for contact and contactless payments.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, digital objects provided by the provisioningnetwork to the DTPU include any one or more of the application selectionmodule (including one or more PSE and PPSE selection applications), thecontainer, the DTP/PDTP and the personalization data for the DTP (ifprovided separately). In embodiments of the present invention and/or inembodiments of its related technologies, the digital objects for theDTPU are created by the provisioning network as APDUs or converted bythe provisioning network from digital object files to APDUs forinstallation on the DTPU.

Provisioning Data (for MCU or Other DPD Component Outside the DTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the data associated with at least one DTP/PDTPincludes at least one cryptographic key associated with a respective atleast one security domain, each at least one security domain associatedwith the respective at least one DTP/PDTP. In such embodiments of thepresent invention and/or in such embodiments of its relatedtechnologies, the at least one cryptographic key is for installation orstorage on the MCU, the OSE or some other component of the DPD externalto the DTPU. In some embodiments, the MCU, the CKSM, the OSE and/or theother component being operable to use the key to encrypt (authenticate)template scripts and/or template commands to become scripts and/orcommands for execution on the DTPU. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the at least one cryptographic key includes at least onekey for a Subsidiary Security Domain (SSD) associated with the DTP/PDTP.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the SSD key is used forencrypting/authenticating communications between the MCU and the DTPU.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the SSD key is stored in securememory on the DTC, wherein the secure memory is external of the DTPU. Insome such embodiments of the present invention and/or in some suchembodiments of its related technologies, the secure memory is acomponent of the MCU. In some such embodiments of the present inventionand/or in some such embodiments of its related technologies, the securememory is within the OSE.

In some other embodiments of the present invention and/or in some otherembodiments of its related technologies, the data associated with atleast one DTP/PDTP includes at least one script for executing commandson the DTPU associated with the at least one DTP/PDTP. In suchembodiments of the present invention and/or in such embodiments of itsrelated technologies, the at least one script is for installation orstorage on the MCU, the OSE or some other component of the DPD externalto the DTPU. In some embodiments of the present invention and/or in someembodiments of its related technologies, the MCU, the OSE, and/or theother component being operable to use the script to execute actions onthe DTPU. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the at least onescript is a standards compliant script encrypted/authenticated by an SSDkey associated with the security domain in which the DTP/PDTP willexecute on the DTPU. The script may include one or more commands foreffecting one or more actions on the DTPU. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the one or more actions include personalizing one or moretransaction applications of the one or more DTPs. In other embodimentsof the present invention and/or in other embodiments of its relatedtechnologies, the one or more actions include locking and/or unlockingtransaction applications.

In yet some other embodiments of the present invention and/or in yetsome other embodiments of its related technologies, the data associatedwith at least one DTP/PDTP includes metadata for operating DPDcomponents outside of the DTPU, wherein the operating is associated withthe at least one PDTP. In such embodiments of the present inventionand/or in such embodiments of its related technologies, the metadata isfor installation or storage on the MCU or some other component of theDPD external to the DTPU. In some embodiments of the present inventionand/or in some embodiments of its related technologies, the MCU and/orthe other component being operable to use the metadata for displayingDTP/PDTP details on a user interface. In embodiments of the presentinvention and/or in embodiments of its related technologies, the dataassociated with at least one PDTP are used by the DPD for displaying aprimary identifier (a PAN for payment card PDTPs), a card image,cardholder name, expiration date, CVV, and other such details associatedwith the PDTP.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, digital objects provided by the provisioningnetwork to the MCU, the OSE or some other component of the DPD externalto the DTPU include the one or more scripts, the one or more securitykeys, and the metadata. In some other embodiments of the presentinvention and/or in some other embodiments of its related technologies,the digital objects for the MCU, the OSE or some other component of theDPD external to the DTPU are created by the provisioning network asdigital files for storage or installation on the MCU and/or the othercomponent.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, digital objects provided by the provisioningnetwork to the MCU, the OSE or some other component of the DPD externalto the DTPU include an updated application selection module manifest,being a file including transaction application identifiers (such asAIDs) associated with DTPs/PDTPs installed or to be installed into theDTPU. In embodiments of the present invention and/or in embodiments ofits related technologies, the MCU, the OSE or some other component ofthe DPD external to the DTPU is operable to update the applicationselection module with the transaction application identifiers in theupdated application selection module manifest. In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the digital objects provided by the provisioning networkto the MCU, the OSE or some other component of the DPD external to theDTPU are in the form of one or more scripts and/or commands, and/or oneor more template scripts and/or template commands.

Provisioning (Delivery to the DTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the digital entities, data, and/or digital objectsfrom the provisioning network to the DTPU are provided via a securecommunication session to the DTPU. In some embodiments of the presentinvention and/or in some embodiments of its related technologies, thesecure communication session is in accordance with one of SCP01, SCP02,SCP03, SCP80 and SCP81 communication protocols. In some suchembodiments, the secure communication session is a synchronous securecommunication session.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the secure communication session is inaccordance with SCP02 i=55. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the secure communication session is an asynchronous secure communicationsession.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the provisioning network is operable,selectively, for both synchronous and asynchronous sessions.

Provisioning (Delivery to the MCU or Other DPD Component Outside theDTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the digital entities, data, and/or digital objectsfrom the provisioning network to the MCU, the CKSM, the OSE or someother component of the DPD external to the DTPU are provided via asecure communication session to the MCU. In some embodiments of thepresent invention and/or in some embodiments of its relatedtechnologies, the secure communication session is in accordance with GPSCP11 communication protocol. In some embodiments of the presentinvention and/or in some embodiments of its related technologies, thesession is a synchronous session. In other such embodiments, the sessionis an asynchronous session. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the provisioning network is operable, selectively, for both synchronousand asynchronous sessions.

In some embodiments of the present invention and/or in some embodimentsof its related technologies, the digital entities, data, and/or digitalobjects from the provisioning network to the MCU, the CKSM, the OSE orsome other component of the DPD external to the DTPU are provided via acommunication using TLS.

In yet other embodiments of the present invention and/or in yet otherembodiments of its related technologies, the digital entities, data,and/or digital objects from the provisioning network to the MCU or someother component of the DPD external to the DTPU are provided via a SEMSor SEMS-like communication.

Transaction Application Instantiation

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the provisioning network includes a DPD manager.In some such embodiments of the present invention and/or in some suchembodiments of its related technologies, the DPD manager is operable toprovide one or more scripts and/or commands to the DTPU of the DPD toinstall one or more transaction applications on the DTPU (eachtransaction application associated with a DTP). In some such embodimentsof the present invention and/or in some such embodiments of its relatedtechnologies, the DPD manager is operable to provide one or more scriptsand/or commands to the DTPU of the DPD to install one or more SSDs foreach one or more DTPs on the DTPU. In some such embodiments of thepresent invention and/or in some such embodiments of its relatedtechnologies, the DPD manager is operable to provide one or more scriptsand/or commands to the DTPU of the DPD to instantiate one or moretransaction applications for each one or more DTPs on the DTPU.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD manager is operable to effect a keyrotation for each of the one or more SSDs. In some such embodiments ofthe present invention and/or in some such embodiments of its relatedtechnologies, the key rotation passes control of each SSD to anotherprovisioning agent in the provisioning network, including a TSM, a TSPor a SEMS, for personalization of the one or more transactionapplications in the DTP. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the key rotation is effected by provision of one or more key rotationscripts and/or commands to the DTPU from the DPD manager. In other suchembodiments of the present invention and/or in other such embodiments ofits related technologies, the key rotation is effected by a CASD on theDTPU. In yet other embodiments of the present invention and/or in yetother embodiments of its related technologies, key rotation is done bythe TSM and/or TSP, but not by the DPD manager.

Personalization

In embodiments of the present invention and/or in embodiments of itsrelated technologies, personalization the process of personalizing a DTPwith data specific to the particular card or other digital document suchthat the DTP becomes a PDTP. In embodiments of the present inventionand/or in embodiments of its related technologies, the personalizationdata may include one or more of: a primary identifier (such as a PAN fora credit or debit card), a cardholder's name, expiry date, a PIN, a CVV,and other data.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, where a DTP is associated with a singletransaction application, the personalization data (or personalizationdetails) will be written into (or associated with) the singletransaction application.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where a DTP is associated withmore than one transaction application, the personalization data (orpersonalization details) will be written separately into (or associatedwith) each of the more than one transaction applications. In some otherembodiments of the present invention and/or in some other embodiments ofits related technologies, where a DTP is associated with more than onetransaction application, a subset of the same personalization data (orpersonalization details) will be written separately into (or associatedwith) each of the more than one transaction applications, wherein thesubset of personalization data (or personalization details) for eachtransaction application of the PDTP is different from others of the morethan one transaction applications.

In some other embodiments of the present invention and/or in some otherembodiments of its related technologies, where a DTP is associated withone or more transaction application, the personalization data (orpersonalization details) includes a tokenized primary identifier (ortokenized PAN) for each of the one or more transaction applications,wherein each tokenized primary identifier is different from others ofthe tokenized primary identifiers, such that, following personalization,the PDTP is a tokenized PDTP having one or more associated tokenizedtransaction applications. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the tokenized PDTP includes one transaction application personalizedwith the primary identifier (a non-tokenized transaction application).In some other such embodiments of the present invention and/or in someother such embodiments of its related technologies, the tokenized PDTPincludes only tokenized transaction applications. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the tokenized personalization data is providedby a TSP in the provisioning network.

In other embodiments of the present invention and/or in otherembodiments of its related technologies, where the PDTP is to beoperable with transaction types, wherein each transaction type isassociated with a transaction application associated with a same primaryidentifier, the DTP is personalized with transaction type identifiers(or identifying information) for each transaction application. In somesuch embodiments of the present invention and/or in some suchembodiments of its related technologies, the transaction typeidentifiers include a sequence number for each associated transactionapplication. In some such embodiments of the present invention and/or insome such embodiments of its related technologies, the transaction typeidentifiers include personalizing each associated transactionapplication with a different tokenized primary identifier. In some suchembodiments of the present invention and/or in some such embodiments ofits related technologies, the transaction type identifiers include thetransaction application identifier (AID) of each transaction application(it will be appreciated that the AID of each transaction application isprovided when the transaction application is initially instantiated andextradited to its associated DTP and/or SSD of the DTP).

Linking DPD to DAD (Using DTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD is operable to link with only onespecified DPD, and the DPD may be uniquely identified by the ID of theDTPU. In other embodiments of the present invention and/or in otherembodiments of its related technologies, the DAD is operable to linkwith multiple DPDs, each of which may be uniquely identified by the IDof their DTPU. In yet other embodiments of the present invention and/orin yet other embodiments of its related technologies, the DPD isoperable to link with only one DAD, and the DAD may be uniquelyidentified by its device fingerprint, which may include itsInternational Mobile Equipment Identity (IMEI) number. In yet furtherembodiments of the present invention and/or in yet further embodimentsof its related technologies, the DPD is operable to link with more thanone DAD, each of which may be uniquely identified by its devicefingerprint.

Linking DPD to DAD (Using MCU or Other DPD Component Outside the DTPU)

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DAD is operable to link with only onespecified DPD, and the DPD may be uniquely identified by the ID of theMCU or Other DPD component outside the DTPU. In other embodiments of thepresent invention and/or in other embodiments of its relatedtechnologies, the DAD is operable to link with multiple DPDs, each ofwhich may be uniquely identified by the ID of their MCU or other DPDComponent Outside the DTPU. In yet other embodiments of the presentinvention and/or in yet other embodiments of its related technologies,the DPD is operable to link with only one DAD, and the DAD may beuniquely identified by its device fingerprint, which may include itsInternational Mobile Equipment Identity (IMEI) number. In yet furtherembodiments of the present invention and/or in yet further embodimentsof its related technologies, the DPD is operable to link with more thanone DAD, each of which may be uniquely identified by its devicefingerprint.

Locking/Unlocking/Active/Inactive/Operable/Inoperable Terminology

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable to store or generate scriptsand/or commands for locking and unlocking transaction applications (andother applications) in the DTPU. In such embodiments of the presentinvention and/or in such embodiments of its related technologies, anunlocked transaction application can be accessed by a DTD for a digitaltransaction, and a locked transaction application cannot be accessed bya DTD for a digital transaction. In some such embodiments of the presentinvention and/or in some such embodiments of its related technologies,the scripts and/or commands for locking/unlocking, and/or the templatescripts and/or template commands for locking/unlocking are stored onand/or generated by the OSE.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a PDTP is inactive when all its associatedtransaction applications are locked. In embodiments of the presentinvention and/or in embodiments of its related technologies, a PDTP isactive when at least one of its one or more associated transactionapplications are unlocked.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a personality is active or operable when itsassociated PDTP is active. In embodiments of the present inventionand/or in embodiments of its related technologies, a personality isinactive or inoperable when its associated PDTP is inactive.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable to have more than onepersonality active or operable. In such embodiments of the presentinvention and/or in such embodiments of its related technologies, ifthere are two or more operable personalities, each personality is for adifferent function, such as one personality being for payments andanother personality being for identification. It will be appreciatedthat a personality for payments uses a different type of DTD from apersonality for identification, so that the operation of thepersonalities in the different DTDs will not conflict.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD is operable to have two paymentpersonalities active or operable (the DTPU having two payment PDTPsactive), however, one of the personalities (and its associated PDTP)must be for contact transactions only, and the other personality (andits associated PDTP) must be for contactless transactions only. It willbe appreciated that a personality (and its associated PDTP) for contactpayments uses a different aspect of a DTD from a personality (and itsassociated PDTP) for contactless payments, so that the operation of thepersonalities (and their respective PDTPs) in the different DTDs willnot conflict.

For the operation of transaction applications (or non-transactionapplications), other terms used include activating/inactivating,blocking/unblocking, activating/deactivating and enabling/disabling. Theterms lock/unlock will be preferred in this specification. The terms mayalso refer to the state of an application, that is, being in either alock(ed) state or unlock(ed) state. Sometimes, instead of specifyingthat one or more transaction applications associated with aPDTP/personality have each been locked/unlocked (as appropriate in thecontext), the PDTP/personality will be described as beinglocked/unlocked or active/inactive (as appropriate in the context).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the security hierarchy of the DTPU is configuredto allow a single command (single script) to be sent to the DTPU to lockall transaction applications for all PDTPs on the DTPU. In embodiments,this is provided by a cascade locking routine from an SSD with aposition in the security hierarchy above all transaction applicationsand PDTPs (and above the SSDs associated with those transactionapplications and PDTPs).

DPD Variations

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with one or morePDTPs/personalities pre-installed, wherein the DPD is not operable forfurther provisioning of PDTPs/personalities.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with one or morePDTPs/personalities pre-installed, wherein the DPD is operable forfurther provisioning of PDTPs/personalities (including personalitymetadata).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with noPDTPs/personalities pre-installed, wherein the DPD is operable forprovisioning of PDTPs/personalities (including personality metadata).

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with one or morecontainers pre-installed, wherein the DPD is operable for furtherprovisioning of one or more containers.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with no containerspre-installed, wherein the DPD is operable for further provisioning ofone or more containers.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with an applicationselection module installed.

In embodiments of the present invention and/or in embodiments of itsrelated technologies, a DPD is provided to a user with no applicationselection module installed, wherein the DPD is operable for furtherprovisioning of an application selection module.

Certifications, Protocols and/or Standards

In embodiments of the present invention and/or in embodiments of itsrelated technologies, the DPD, or one of its components including theDTPU, the MCU, OSE, CKSM and other components on the DPD, comply withone or more of the following certifications, protocols and/or standards:

GlobalPlatform Industry Configuration Certification:

-   -   Finance Configuration specification v1.0;    -   UICC Configuration specification v2.0;    -   UICC Configuration specification v1.0.1.

GlobalPlatform functionality and features:

-   -   Secure Messaging (such as SCP 02 option i=‘55’);    -   Secure Messaging (such as SCP 03 option i=‘10’, ‘30’ and ‘70’);    -   Secure Messaging (such as SCP81 with TLS 1.0-1.2 with all PSK        cipher suites);    -   GlobalPlatform Card Specification v2.1.1 or 2.3;    -   GlobalPlatform Card v2.2.1 or 2.3 Amd. A;    -   GlobalPlatform Card v2.2.1 or 2.3 Amd. B (SCP81);    -   GlobalPlatform Card v2.2.1 or 2.3 Amd. C;    -   GlobalPlatform Card v2.2.1 or 2.3 Amd. D;    -   GlobalPlatform Card v2.1.1 (on card GP applet API);    -   Key Management (including Put Key and Store Data GP commands)        for 3DES, and may also include DES, AES, RSA (1024 & 2048 bit)        and ECC keys;    -   Data Store (for operations such as storage and retrieval of DGI        objects);    -   Card Content Management (for operations such as loading,        installing, and deleting applications) for 3DES, and may also        include AES, RSA (1024 & 2048 bit) and ECC algorithms;    -   Security Domain Tree (for operations such as deletion and        extradition with the Security Domain hierarchy);    -   Confidential Card Content Management (such as Security Domain        personalization using Controlling Authority Security Domain        (CASD));    -   Logical Channel Management.

GlobalPlatform Privileges:

-   -   Security Domain;    -   Trusted Path;    -   Global Registry;    -   Global Delete;    -   Global Lock;    -   Authorized Management.

Finance Certification:

-   -   Contact L1 EMVCo Protocol & Electrical;    -   Contactless L1 EMVCo Analogue & Digital;    -   Contact L2 EMVCo CPA & CCD;    -   Contact L2 VISA Integrated Circuit Card Spec (VIS);    -   Contactless L2 VISA Contactless Payment Spec (VCPS);    -   Contactless L2 VISA Mobile Payment Application (VMPA);    -   Contact L2 MasterCard M/Chip;    -   Contactless L2 MasterCard PayPass M/Chip advance;    -   Contactless L2 Mobile MasterCard PayPass (MMPP);    -   Contact L1 AEIPS Chip Card Spec;    -   Contactless L2 ExpressPay Card Spec;    -   Contactless L2 Express Mobile Functional (AEMF);

Transport Layer Protocols:

-   -   NFC-P1 ISO 18092 & NFC-P2 ISO 21481;    -   ETSI 102 613 (SWP) and ETSI 102 622 (HCl).

Transaction Interface Protocols:

-   -   ISO 7816;    -   ISO 14443.

Each of the above-listed certifications, protocols and/or standards isincorporated into this specification by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is an illustration of the exterior of an embodiment of a DTC.

FIG. 1B is a diagram of components in an embodiment of a DTC.

FIG. 1C is an illustration of the exterior of an embodiment of a DTC.

FIG. 2 is an embodiment of metadata associated with a personality.

FIG. 3 is a diagram of components in a further embodiment of a DTC.

FIG. 4 is a diagram of electrical connections between contact pads, anMCU and a DTPU in an embodiment of a DTC.

FIG. 5 is a diagram of an embodiment of a provisioning infrastructure,DAD, DTC and payment network.

FIG. 6 is a tree diagram of an embodiment of a security hierarchy in aDTPU.

FIG. 7 is a tree diagram of an embodiment of a security hierarchy in aDTPU.

FIG. 8 is a tree diagram of an embodiment of a security hierarchy in aDTPU.

FIG. 9A is a tree diagram of an embodiment of part of a securityhierarchy in a DTPU, showing a SSD and transaction applicationsassociated with a PDTP.

FIG. 9B is a tree diagram of an embodiment of part of a securityhierarchy in a DTPU, showing a SSD and transaction applicationsassociated with a PDTP.

FIG. 9C is a tree diagram of an embodiment of part of a securityhierarchy in a DTPU, showing a SSD and transaction applicationsassociated with a PDTP.

FIG. 10 is a sequence diagram showing part of an embodiment of a processfor adopting a personality on a DTC.

FIG. 11 is a sequence diagram showing part of an embodiment of a processfor adopting a personality on a DTC.

FIG. 12 is a tree diagram of a further embodiment of a securityhierarchy in a DTPU.

FIG. 13 is a tree diagram of a further embodiment of a securityhierarchy in a DTPU.

FIG. 14 is a tree diagram of a further embodiment of a securityhierarchy in a DTPU.

FIG. 15 is a tree diagram of a further embodiment of a securityhierarchy in a DTPU.

FIG. 16 is a tree diagram of an embodiment of a branch of a securityhierarchy in a DTPU.

FIG. 17 is a tree diagram of an embodiment of a branch of a securityhierarchy in a DTPU.

FIG. 18 is a diagram of an embodiment of a provisioning infrastructure,DAD, and DTC.

FIG. 19 is a diagram of an embodiment of a provisioning infrastructure,DAD, and DTC.

FIG. 20 is a diagram of an embodiment of a provisioning infrastructure,DAD, and DTC.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

FIGS. 1A and 1B show the main components of an embodiment of a DigitalPayment Device (DPD) 12 in accordance with the invention. In theembodiments illustrated in the figures, the Digital Payment Device (DPD)is exemplified as a DTC. In at least some embodiments, the DTC hasdimensions and a shape which conform to specifications for a traditionalplastic transaction card, such as a credit card, which is suitable foruse in an automated teller machine or contact payment terminal. Forexample, the DTC can be in accordance with at least one of ISO 7816-1(physical characteristics), ISO 14443-1 (physical characteristics), andISO 7816-2 (location of contacts). It will be appreciated that in otherembodiments the DPD can have a different shape and/or dimensions, andcan for example be configured for use in wearable applications (forexample a ring, pendant or watch), non-wearable goods (for example arefrigerator or vehicle), non-payment applications (for example anidentity document), and transport payment devices.

In the prior art, a plastic credit card or debit card has a singleoperable personality provided by a single issuer, for example a singlebank. Some cards in the prior art are operable to route transactionsthrough two payment schemes (also known as payment networks) whichconsist of a single domestic payment scheme (for example, EFTPOS inAustralia, Interac in Canada, or RuPay in India), and a singleinternational payment scheme (for example, Visa or Mastercard). Suchcards include a different transaction application for each paymentscheme, but only include transaction applications for a singleinternational payment scheme and a single domestic payment scheme. Suchprior art cards do not include transaction applications for twodifferent international payment schemes, and do not include transactionapplications for two different domestic payment schemes. One transactionapplication on the card is used whenever the card performs a transactionwith a Digital Transaction Device (DTD), for example a POS terminal. TheDTD selects an appropriate transaction application to be used, forexample a domestic transaction application or an internationaltransaction application. Some cards have separate transactionapplications for contact and contactless transactions. Again, the DTDselects an appropriate transaction application to be used.

Since transaction cards of the prior art have only one operablepersonality, there is no possibility to select a personality from one ormore personalities hosted by the card. Where a card has a plurality oftransaction applications, there is no facility on the card itself toselect one particular transaction application for use in a transaction.

In embodiments of the present invention, the DTC 12 is operable to hostone or more personalities and the DTC is operable to adopt a personalityselected from one or more hosted personalities. The one or more hostedpersonalities can be associated with at least one issuer. In anembodiment, the DTC 12 is operable to host a plurality of personalitiesincluding at least one personality associated with a first issuer and atleast one personality associated with a second issuer. In an embodiment,the DTC is operable to host one or more personalities associated withthe same issuer.

In an embodiment, the DTC 12 is operable to host one or more transactionapplications associated with at least one domestic payment scheme. In anembodiment, the DTC 12 is operable to host one or more transactionapplications associated with at least one international payment scheme.In an embodiment, the DTC 12 is operable to host a plurality oftransaction applications including at least one transaction applicationassociated with a first domestic payment scheme and at least onetransaction application associated with a second domestic paymentscheme. In an embodiment, the DTC 12 is operable to host a plurality oftransaction applications including at least one transaction applicationassociated with a first international payment scheme and at least onetransaction application associated with a second international paymentscheme.

A “hosted” personality is one which is installed on the DTC. Aninstalled personality is either in an active state or an inoperablestate. A personality in an active state (an “active” personality) iscapable of being used by the DTC in a transaction with a DTD. Apersonality in an inoperable state (an “inoperable” personality) cannotbe used by the DTC in transactions with a DTD. An inoperable personalityis available to be made active (activated) while the DTC is in thefield, and an active personality can be made inoperable (de-activated)while the DTC is in the field. The DTC is operable to enable acardholder to initiate the activation or de-activation of a personalitywhile the DTC is in the field.

Activating a personality is also referred to as adopting a personality.Changing the active personality/personalities is also simply referred toas changing the personality. An embodiment of a process foractivating/adopting a personality is described below with reference toFIGS. 7-8 and 10-11.

Referring to FIG. 1A, an example of a DTC 12 is shown in which threepersonalities 7, 8, 9 are installed on (hosted by) the DTC 12. The threepersonalities 7, 8, 9 correspond to three transaction accounts issued byvarious payment schemes and banks:

-   -   personality 7: Visa credit account (issued by Bank 1);    -   personality 8: Mastercard debit account (issued by Bank 1); and    -   personality 9: American Express credit account (issued by Bank        2).

Each personality 7, 8, 9 represents a different transaction account andenables the DTC to conduct transactions with one specific transactionaccount. To conduct a transaction with a transaction account, thepersonality associated with the transaction account must be adopted bythe DTC. The adoption is triggered by a cardholder.

Each hosted personality 7, 8, 9 is associated with a single PersonalizedDigital Transaction Package (PDTP). An active personality is associatedwith an active PDTP, and an inoperable personality is associated with aninoperable PDTP.

Each PDTP is associated with at least one transaction application,therefore each personality is also associated with at least onetransaction application. A transaction application which is inoperablefor transactions with the DTC is referred to as being “locked”, and atransaction application which is operable for transactions with the DTCis referred to as being “unlocked”. A locked transaction application isnot selectable in a transaction with a DTD, even with direct selection.

The DTC 12 includes a user interface 83A, 83B which can be used by acardholder to select one of the personalities or transactionapplications for use in a transaction. In this embodiment, the userinterface includes a display screen 83A (for example a dot matrixdisplay) and a button keypad 83B. In another embodiment the userinterface includes a touchscreen display instead of a keypad.

In an embodiment, the DTC 12 enables the cardholder to select and adopta transaction application from a plurality of transaction applicationsassociated with the same personality. For example, FIG. 1C shows Visacredit account personality 7 associated with a plurality of transactionapplications. The display screen 83A presents three respective options 6(shown as “App 1”, “App 2”, and “App 3”) which are indicative of threerespective transaction applications (all of which are associated withthe same personality 7). The three transaction applications could, forexample, be associated with three different types of transaction, suchas transactions in three different currencies, or transactionsassociated with three different expense categories. Further examples oftransaction types are described below with reference to FIGS. 9A to 9C.

Where an active PDTP is associated with a plurality of transactionapplications, the PDTP may be associated with one or more unlockedtransaction applications and one or more locked associated transactionapplications. Such a PDTP (and associated personality) is considered tobe active because it is operable to be used in at least sometransactions.

In an embodiment, a personality is installed on the DTC 12 by providingvarious digital objects to the DTC. In at least some embodiments of theinvention, the DTC 12 includes security arrangements to accept digitalobjects only from an authorised provider. Such security arrangementsinclude being operable to check the authenticity of any digital objectsto be installed. In an embodiment, digital objects associated with apersonality installation are provided by a provisioning infrastructure10 with suitable encryption and authentication protocols. An embodimentof a provisioning infrastructure 10 is described below.

In embodiments of the invention, the DTC includes a DTPU 30 which isoperable to host a plurality of transaction applications and at leasttwo of the plurality of transaction applications are associated with anidentical primary PAN. The DTC is operable to reversibly unlock at leastone transaction application on the DTPU, and to reversibly lock anyother transaction application on the DTPU.

In the following description of embodiments of the invention, the DTC isoperable to host one or more personalities and to adopt a personalityfrom the one or more personalities. The invention also includesembodiments in which the DTC is operable to host a personalityassociated with one or more transaction applications.

Referring to FIG. 1B, the DTC includes a DTPU 30 which is operable tohost at least one PDTP, and at least one transaction applicationassociated with each PDTP. The DTC is operable to reversibly unlock atleast one transaction application on the DTPU, and to reversibly lockany other transaction application on the DTPU. The DTPU 30 is operableto adopt a PDTP selected from one or more hosted PDTPs and to perform adigital transaction with a DTD using the adopted PDTP.

The DTC 12 in this embodiment has interfaces for performing both contactand contactless transactions. In an alternative embodiment, the DTC 12is operable to perform only contactless transactions, and in a furtheralternative embodiment, the DTC 12 is operable to perform only contacttransactions. In the embodiment shown in FIG. 1B, contact transactionsare conducted via a contact plate 34 and contactless transactions areconducted via an NFC antenna 92, as is well known in the prior art. Thecontact plate 34 has an external interface for the DTPU 30 and MCU 32and enables data communication between the DTPU 30 and an MCU 32. TheMCU 32 is also in data communication with an Operational Secure Element(OSE) 80, a secure memory 84, a communications module 86, and the userinterface 83A, 83B.

The MCU 32 is operable to perform various operations on the DTC 12,including: routing digital objects to other components on the DTC 12,generating a list of AIDs for a personality selected by a cardholder,requesting scripts from a script applet 81 on the OSE 80, and forwardingscripts to the DTPU 30, reading and writing information to and from thesecure memory 84, and managing the user interface 83A, 83B. The MCU 32is also used during a process of provisioning the DTC 12, in which apersonality or other functionality is installed on the DTC 12.Provisioning can occur while the DTC 12 is in a factory beforedistribution to the cardholder, or in at least some embodiments, whenthe DTC is physically remote from a provisioning infrastructure 10(shown in FIG. 5). Being remote from the provisioning infrastructure 10is referred to here as being “in the field”.

In the depicted embodiment, the DTPU 30 is a tamper-resistant secureelement suitable for performing financial transactions and capable ofsecurely hosting applications and their confidential and cryptographicdata (for example cryptographic keys) in accordance with the relevantrules and security requirements. The DTPU 30 has aGlobalPlatform-compliant (GP-compliant) operating system installedthereon and sufficient user memory to install multiple personalitieswhich includes being operable to install multiple payment schemecontainers, multiple PDTPs, and a security hierarchy with multiplesupplementary security domains (SSDs). The SSDs in the securityhierarchy include at least one SSD 94 associated with PDTPs, and atleast one SSD 96 associated with an application selection module. TheDTPU 30 stores multiple cryptographic keys including at least one ISDkey 98 for an ISD of the DTPU, at least one SSD key 100 for each SSD 94associated with PDTPs, and an SSD key 102 for the SSD 96 associated withthe application selection module. The keys 98, 100, 102 are used by theDTPU 30 to authenticate a script to be executed thereon.

In an embodiment, the DTPU 30 is in an OP_READY or INITIALIZED statewhile in the factory, and the state must be changed to SECURED (usingappropriate keys for authentication) before distribution to acardholder.

The GP-compliant operating system on the DTPU 30 includes a “GlobalLock” privilege which enables the locking and unlocking of a transactionapplication on the DTPU. When all transaction applications of a PDTP arelocked, the PDTP and associated personality are inoperable. When one ormore transaction applications of a PDTP are unlocked, the PDTP andassociated personality are considered to be active. As each PDTP isassociated with a personality, de-activating a PDTP effectivelyde-activates the associated personality, and activating a PDTP activatesthe associated personality. The locking and unlocking of transactionapplications and the activation and de-activation of PDTPs are describedbelow.

In at least some embodiments, the DTC is operable to simultaneously havemultiple personalities in an active state. However, it is preferablethat the simultaneously active personalities are those that would nothave the potential to compete or conflict with each other during atransaction. For example, when conducting a contactless payment, a firstpersonality which is exclusively associated with contact transactionsapplication would not compete with a second personality which isexclusively associated with contactless transaction applications, sothere would not be a conflict. Similarly, a personality for a document(e.g. a drivers license) could not take part in a financial transaction,so the document personality can be simultaneously active with anypersonality for a financial transaction. In an embodiment, the MCUcontrols which of the personalities are operable to be simultaneouslyactive. The MCU can refer to rules stored on the DTC, for example in anMCU register. Such rules can be recorded in metadata associated withpersonalities.

In an embodiment, the DTPU 30 is operable to use the Global Lockprivilege to lock all transaction applications installed on the DTPU andthen unlock one or more transaction applications associated with a PDTP(which is associated with a personality selected by the cardholder),while the DTC is in the field without the DTC communicating with theprovisioning infrastructure 10. In an embodiment, such locking andunlocking of transaction applications can be triggered by a cardholderinteracting with the user interface 83A, 83B and making a personalityselection. In an alternative embodiment, the locking and unlocking oftransaction applications can be triggered by a cardholder interactingwith the DAD 14 and making a personality selection, and the DAD isoperable to communicate the cardholder's personality selection to theDTC 12.

As will be described, the Global Lock action is implemented by executingone or more authenticated scripts in the DTPU 30. The MCU 32 is operableto initiate a process of generating such authenticated scripts.Authenticated scripts are generated by a command generation unit whichin this embodiment is an applet referred to as a script applet 81. Thescript applet 81 uses a script template from a template store 82, andkey(s) 104 to generate authenticated scripts which include commands. Thetemplate store 82 stores one or more script templates which are notfunctioning scripts until certain values are filled in, for example anAID of a target application in the DTPU. In the embodiment in FIG. 1B,the script applet 81, template store 82, and SSD key 104 are all storedin the OSE 80. The process of generating authenticated scripts isdescribed in more detail below with reference to FIGS. 7-8 and 10-11.

Plastic credit or debit cards and digital wallets in the prior art donot have the capacity to generate authenticated scripts. In the case ofplastic cards in the prior art, authenticated scripts are preparedexternally (for example, by a perso bureau) and provided to the cardwhile the card is in a secure environment such as a perso bureau. In thecase of digital wallets in the prior art, authenticated scripts areprepared externally (typically by a TSM) and transmitted to the digitalwallet for execution.

In the depicted embodiment, the OSE 80 is a tamper resistant secureelement. In one embodiment, a GP-compliant operating system is installedon the OSE 80, and in another embodiment the OSE 80 does not include aGP-compliant operating system. In an embodiment, a security hierarchywith at least one SSD is installed on the OSE 80.

In the embodiment depicted in FIG. 1B, the secure memory 84 is a tamperresistant storage area which does not include a GP-compliant operatingsystem. For example, the secure memory 84 can include ultra-securehardware-based cryptographic key storage and cryptographiccountermeasures designed to reduce or eliminate potential backdoorslinked to software weaknesses. The MCU 32 has read and write access tothe secure memory 84 and is operable to store digital objects in thesecure memory 84 that do not require a GP-compliant operating system,for example Bluetooth keys and metadata associated with a personality.In an alternative embodiment, the DTC does not include a secure memory,and digital objects such as Bluetooth keys and metadata are insteadstored in the MCU 32.

Referring to FIG. 3, an alternative embodiment of a DTC 12 is shown inwhich the script applet 81, template store 82, SSD key 104, and MCUregistry 35 are included on a secure MCU 33. In this embodiment thefunction of the OSE 80 (shown in FIG. 1B) is performed by the secure MCU33. Further, the DTPU 30 and secure MCU 33 are incorporated into asingle integrated circuit chip 37 (indicated by a dotted line 37 in FIG.3). The script applet 81, template store 82 and SSD key 104 shouldalways be stored securely as they enable the generation of scriptscapable of being executed on the DTPU 30. Therefore, the secure MCU 33should have a level of security which is accordance with the relevantrules and security requirements. In an alternative embodiment (notshown), the secure MCU 33 and DTPU 30 are provided as separate chips.

The Communications Module of the DTC

At times, the DTC may need to be provisioned with digital objects from aprovisioning infrastructure 10 (described below with reference to FIGS.18-20) which is remote from the DTC. The DTC is operable to communicatewirelessly with the provisioning infrastructure by communicating with aData Assistance Device (DAD) which in turn is operable to communicatewith the provisioning infrastructure. For example, the DAD can be amobile device such as a smart phone. The DTC in this embodiment is alsooperable to communicate directly with the provisioning infrastructure byWiFi without using a DAD. For such wireless communications (with the DADand using WiFi), the DTC includes a communications module 86. In thisembodiment, the communications module 86 includes a WiFi module 88(which includes a WiFi chip and antenna), a Bluetooth module 90 (whichincludes a Bluetooth chip and antenna), and the NFC antenna 92. In thecase of Bluetooth and NFC communications, the communications moduleenables the DTC 12 to be linked to (sometimes referred to as beingpaired with) the DAD for intercommunications.

The NFC antenna 92 is directly connected to the DTPU 30, whereas theBluetooth module 90 and WiFi module 88 are connected to the MCU 32. TheWiFi module 88, Bluetooth module 90 and NFC antenna 92 may be discretecomponents but are referred to collectively as the communications module86. In other embodiments of the DTC 12, the communications module 86does not have all three items 88, 90, 92, but includes at least one of aWiFi module, a Bluetooth module, and an NFC antenna. In one embodiment,the communications module 86 consists of the Bluetooth module 90. Inanother embodiment, the communications module 86 consists of the WiFimodule 88. In another embodiment, the communications module 86 consistsof both the WiFi module 88 and the Bluetooth module 90. Alternatively,any other suitable apparatus for wireless communication can be includedin the communications module 86.

MCU, OSE and DTPU Connections

In an embodiment, a communication link 106 between the MCU 32 and OSE 80uses a serial communication protocol. A communication link 108 betweenthe DTPU 30 and the contact plate 34 is in accordance with the ISO 7816standard, as is well known in the prior art. Unlike the prior art, thedepicted embodiment illustrates a communication link 110 between the MCU32 and the contact plate 34. In one embodiment, link 110 is inaccordance with the ISO 7816 standard. In another embodiment, link 110uses a serial communication protocol. Links 108, 110 enable commandAPDUs (C-APDUs) to be transmitted from the MCU to the DTPU 30, andresponse APDUs (R-APDUs) to be transmitted from the DTPU to the MCU.

FIG. 4 shows further details of the communication links between thecontact plate 34 and the DTPU 30 and MCU 32 (shown in FIG. 1B). As isknown in the prior art, the DTPU 30 is connected to five patterned metalcontact pads within the contact plate 34, having standard functions: VCC(pad 122), RESET (pad 124), CLOCK (pad 126), GROUND (pad 128), and DATA(pad 130). These five contact pads (122, 124, 126, 128, 130) areconventionally used in financial transactions to exchange APDUs betweena DTD (for example, a POS terminal) and the DTPU 30. In the embodimentin FIG. 4, the five contact pads (122, 124, 126, 128, 130) are alsoconnected to the MCU 32. As indicated in FIG. 1B, the MCU has alsocommunication links with the other components on the DTC (the OSE 80,user interface 83A, 83B, secure memory 84, Bluetooth module 90, and NFCantenna 92) and these links are indicated by lines 136 in FIG. 4.

The contact plate 34 depicted in FIG. 4 also includes two pads 132, 134which are connected to the MCU 32 but not to the DTPU 30. The pads 132,134 are specified by ISO 7816 to be used for custom applications, and inthis embodiment pads 132, 134 are provided to enable serialcommunications with the MCU 32. In this embodiment, pad 132 is operableto transmit data to the MCU 32, and pad 134 is operable to receive datafrom the MCU. Custom contact pins will likely be required to contactpads 132, 134. It is anticipated that pads 132, 134 may be used in afactory or similar environment (for example a perso bureau) forprovisioning the MCU with digital objects before the DTC is distributedto a cardholder. For example, digital objects provisioned via pads 132,134 could include digital objects intended for the MCU 32 or digitalobjects for relocation (by the MCU) to either the OSE 80, secure memory84, or communications module 86. The five contact pads (122, 124, 126,128, 130) enable the DTPU 30 to be provisioned directly without usingthe MCU 32 to route digital objects to the DTPU, for example whentransmitting scripts to the DTPU while the DTC is in the factory or incontact mode with a DTD.

In at least some embodiments, a switch (not shown) is included todisconnect the MCU 32 from pads 132, 134 when these pads are not in use,to avoid unwanted voltages inadvertently affecting the MCU and the riskof hacking via pads 132, 134.

The same communication links shown in FIG. 4 are also used in theembodiment shown in FIG. 3 between the contact plate 34, DTPU 30, andsecure MCU 33 (in place of the MCU 32).

Metadata

The DTC 12 and DAD 14 store metadata associated with each personalityhosted by the DTC. Such metadata is used by the MCU when changing theactive personality on the DTC. The metadata enables the MCU to look upan AID of each transaction application associated with a selectedpersonality and then request the script applet 81 to generate one ormore scripts in respect of the AID(s). In an embodiment, at least someof the metadata is displayed on the display screen 83A to indicate theactive personality/personalities.

FIG. 2 shows an embodiment of metadata for one personality. In thisembodiment, the metadata is stored as a table in which a first column888 comprises scheme name, issuer name, cardholder name and AID list, asecond column 890 comprises the full PAN (personal account number orprimary account number), the last four digits of the full PAN, expirydate and CVV, and a third column 892 comprises a nickname (generated bythe cardholder) for the personality. In this embodiment, such metadatais stored on the MCU 32 in an MCU registry 35 (shown in FIG. 1B). Inalternative embodiments, the metadata is stored outside the MCU 32. Inan embodiment, the metadata is stored in the secure memory 84, and inanother embodiment the metadata is stored in the OSE 80.

In an embodiment in which a PDTP is associated with a plurality oftransaction applications and the DTC 12 is operable to unlock at leastone transaction application (from the plurality of transactionapplications) and to lock all other of the plurality of transactionapplications, the DTC 12 stores additional metadata about the pluralityof transaction applications. In an embodiment, metadata is stored foreach transaction application and at least some of the metadata can bedisplayed on the display screen 83A. The metadata enables the MCU tolook up each AID associated with each selected transaction applicationand then request the script applet 81 to generate one or more scripts inrespect of the AID(s). In an embodiment, the metadata for eachtransaction application includes at least the following information:primary PAN, AID, identifying information, nickname, operation mode(contact or contactless). In an embodiment, the identifying informationin the metadata is a tokenised PAN. In another embodiment, theidentifying information is a sequence number. The purpose of theidentifying information is to enable an issuer to identify a transactionapplication that has been used in a transaction.

Provisioning the DTC

The purpose of provisioning is to provide digital objects to the DTC 12,for example to give operational functionality to the DTC, or to installa personality. Examples of such digital objects include data forinstalling firmware needed for operation of the DTC (for example, MCUfirmware), and for providing scripts, keys, payment scheme containers,metadata, and applications (including transaction applications, PDTPs,and selection applications). Scripts can be provided to the DTC toperform many functions on the DTC, including installing a payment schemecontainer, installing a DTP from a payment scheme container,personalising a DTP, and installing a security hierarchy in the OSE orDTPU, amongst others.

In an embodiment, the DTC is at least partially “pre-provisioned” in afactory, which means being provisioned with digital objects in a factoryenvironment prior to the DTC being distributed to a cardholder in thefield. The DTC in this embodiment is operable to be further provisionedin the field by the provisioning infrastructure 10. Pre-provisioning inthe factory includes provisioning with the involvement of a componentmanufacturer, device assembly operation, device testing operation, keyinjection partner, lamination factory, perso bureau or any other partyinvolved in the manufacture or preparation of the DTC before it reachesthe field. At least some of the digital objects required to provisionthe DTC are provided to the factory by the provisioning infrastructure10.

In one version, the DTC is pre-provisioned in the factory with at leastone of firmware, a GP-compliant security hierarchy, a cryptographic key,a payment scheme container, a PDTP, and a selection application. Forexample, the DTC can be pre-provisioned with digital objects to installa number of personalities, and the DTC can be operable to be provisionedin the field (by the provisioning infrastructure 10) so as to install atleast one more personality on the DTC. Alternatively, the DTC may bepre-provisioned with one or more payment scheme containers, and the DTCis operable to be provisioned in the field (by the provisioninginfrastructure 10) so as install a PDTP from the one or more installedpayment scheme containers.

In an alternative embodiment, the DTC is distributed to a cardholderafter very little pre-provisioning in the factory, and is operable to belargely provisioned in the field by the provisioning infrastructure 10.In such an embodiment, the DTC is pre-provisioned with rudimentarybootstrap firmware (installed on the MCU) and keys, for example a TLScertificate, a key for decryption of a subsequent firmware update (forexample a PKI key), and DTPU keys to enable the DTPU to be supplied in aSECURED state.

In an alternative embodiment, the DTC is pre-provisioned in the factorywith a plurality of personalities and the DTC is not capable of beingprovisioned in the field. This embodiment of the DTC is also capable ofhosting a plurality of personalities and for adopting a personality fromthe plurality of personalities while the DTC is in the field.

Interactions with a Payment Network

Referring to FIG. 5, at least some embodiments of the DTC 12 areoperable to conduct financial transactions with a conventional paymentnetwork including a DTD 70 (for example a POS terminal) whichcommunicates with the DTC 12, an acquirer 72, a payment scheme 74, andthe issuer 18. In the embodiment shown in FIG. 5, a provisioning network16 (described below) is not involved in the process of conducting atransaction. However, the provisioning network 16, together with theissuer 18, are operable to provision the DTC 12 with digital objectsthat enable the DTC 12 to conduct transactions with a conventionalpayment network.

Embodiment of a Security Hierarchy

FIG. 6 illustrates an embodiment of a security hierarchy 201 on the DTPUwhich is suitable for hosting a plurality of personalities and foradopting a personality from the plurality of personalities while the DTCis in the field.

The security hierarchy 201 has a tree structure. The highest level ofthe security hierarchy is the Issuer Security Domain (ISD) 200. The ISDin this embodiment is a parent to three SSDs (202, 96, 206) which areeach a parent to three sibling branches of the tree structure anddescribed below. Each SSD in the hierarchy holds at least onecryptographic key which is operable to authenticate scripts targetingthat SSD. For example, SSD 206 holds a key which is operable toauthenticate any script targeting SSD 206. Only a party that has a copyof the appropriate key for a specific SSD can authenticate scriptstargeting that SSD.

SSD 96 is a parent to a first branch of the tree structure. The firstbranch includes a PSE selection application 222, a PPSE selectionapplication 224, and a container 226. A copy of the key held by SSD 96is also held by the OSE 80 (shown in FIG. 1B) and a provisioning network16 (specifically a DPD manager 36, as shown in FIGS. 18-20). Therefore,the OSE 80 and DPD manager 36 are each operable to authenticate scriptstargeting SSD 96 and the applications 222, 224 associated with SSD 96(in the terminology of a tree structure, applications 222, 224 are eacha “child” of SSD 96). The PSE and PPSE selection applications areinstalled from the container 226 which in the form of at least oneElementary Load File (ELF).

SSD 206 is parent to a second branch of the tree structure. The secondbranch is a sibling to the first branch. SSD 206 is a parent to SSD 228and SSD 236, each of which is under the control of a different party,for example a bank. SSD 228, which is controlled by “Bank 1”, is aparent to three further SSDs 242, 244, 246, and each of these furtherSSDs is a parent to one PDTP (which includes at least one transactionapplication) for a single personality:

-   -   SSD 242 is a parent to PDTP 230 for a Bank 1 Visa personality;    -   SSD 244 is a parent to PDTP 232 for a Bank 1 Mastercard        personality;    -   SSD 246 is a parent to PDTP 234 for a Bank 1 American Express        personality.

Only Bank 1 has a copy of the keys held by SSDs 228, 242, 244, 246. Bank1 would use its own SP-TSM to perform operations on SSDs 228, 242, 244,246.

“Bank 2” controls SSD 236, which is a parent to two further SSDs 248,250, and each of these further SSDs is a parent to a PDTP (whichincludes at least one transaction application) for a single personality:

-   -   SSD 248 is a parent to PDTP 238 for a Bank 2 Visa personality;    -   SSD 250 is a parent to PDTP 240 for a Bank 2 Mastercard        personality.

Only Bank 2 has a copy of the key held by SSDs 236, 248, 250. Bank 2would use its own SP-TSM to perform operations on SSD 236, 248, 250.

SSD 202 is a parent to a third branch of the tree structure. The thirdbranch and is a sibling to the first and second branches. SSD 202 is aparent to three SSDs: SSD 210 (which is a parent to a payment schemecontainer 216 for Visa), SSD 212 (which is a parent to a payment schemecontainer 218 for Mastercard), and SSD 214 (which is a parent to apayment scheme container 220 for American Express). Each payment schemecontainer is used to generate (instantiate) an unpersonalisedtransaction application which (when combined with personalisation data)is used to create a transaction application. For example, the container216 for Visa in FIG. 6 would have been used to generate unpersonalisedVisa transaction applications for Bank 1 and Bank 2, which weresubsequently personalised to create each transaction applicationincluded in Visa PDTP 230 and each transaction application included inVisa PDTP 238.

Within the DTPU is an additional security domain 208 known as aControlling Authority Security Domain (CASD). The CASD 208 in thisembodiment is a domain which is trusted by both the DPD manager and themanagers of PDTPs on the DTPU. This embodiment, Bank 1 and Bank 2 arethe managers of the PDTPs on the DTPU. The CASD can be used to perform akey rotation, which is where a key provided by one party (for example,the DPD manager) is swapped for a key provided by another party (forexample, a PDTP manager). A key rotation may be used after the DPDmanager installs an SSD (for example, an SSD associated with a newpersonality) to give control of the SSD to the relevant PDTP manager(for example, Bank 1 or Bank 2). In some embodiments, the CASD ispresent on the DTPU when issued by a chip manufacturer or provider. Inanother embodiment, a CASD is installed when the DTC is in a securefactory environment and prior to the issuer 18 having access to the DTC(to avoid the possibility of tampering by the issuer). In embodiments inwhich there is trust between the DPD manager and the manager of eachPDTP, a CASD may not be required. In some of such embodiments, the DTPUdoes not include a CASD.

Embodiments of an Application Selection Module

A function of the application selection module 225 is to enable the DTC12 to provide an identifier for each transaction application on the DTPU30 which is unlocked and therefore available to be used in a transactionwith a DTD 70 (for example a POS terminal 70 shown in FIG. 5). In theembodiments described here, the identifier is a AID (applicationidentifier) known in the prior art, but the identifier can alternativelybe any information which is capable of identifying a transactionapplication and can be recognised and processed by a DTD 70 and complieswith relevant standards and agreements for payment networks, paymentprocessing methods, and DPDs for such payment networks.

In at least some embodiments, the DTC 12 is operable to unlock selectedtransaction applications and to lock any other transaction applicationon the DTPU 30. Each selected transaction application can be associatedwith one or more PDTPs. Such embodiments of a DTC 12, when performing atransaction with a DTD 70, are operable to provide to the DTD an AID foreach unlocked transaction application on the DTPU 30, without providingan AID for any locked transaction application. The set of AIDs providedby the DTC 12 to the DTD 70 is referred to here as a “candidate list”.During a transaction, the DTD 70 selects an AID from the candidate list,and the selected AID is subsequently used in the transaction.

In an embodiment of the invention, the application selection module 225is operable to generate the candidate list during a transaction, and theDTPU 30 is operable to provide the candidate list to the DTD 70. Thecandidate list must only include transaction applications which arecurrently unlocked. If a personality is subsequently activated orde-activated (and a transaction application is therefore unlocked orlocked, respectively), such a change in state must be reflected in thecandidate list during a subsequent transaction.

In an embodiment, the application selection module 225 is operable togenerate a candidate list for many kinds of transaction application,including a transaction application associated with a payment scheme(for example, a credit or debit account personality), a transactionapplication associated with a non-payment personality (for example, anidentity document), a transaction application associated with atransport smart card personality, a transaction application for contacttransactions, a transaction application for contactless transactions,and a transaction application with interfaces for both contact andcontactless transactions. Such transaction applications includetransaction applications with different primary PANs, transactionapplications with the same primary PAN, transaction applications withdifferent tokenised PANs, and transaction applications with differentsequence numbers.

In an embodiment in which the DTC 12 hosts at least one transactionapplication for a payment scheme, the application selection module 225includes the PSE selection application 222 and the PPSE selectionapplication 224. In an embodiment in which each transaction applicationhosted by the DTC 12 is a contact transaction application (operable forcontact transactions only), the application selection module 225 may notinclude the PPSE selection application 224. In an embodiment in whicheach transaction application hosted by the DTC 12 is a contactlesstransaction application (operable for contactless transactions only),the application selection module 225 may not include the PSE selectionapplication 222. In all such embodiments, the application selectionmodule 225 is operable to perform a process in which the PSE selectionapplication (if included) is set with an AID of each unlocked contacttransaction application, and the PPSE selection application 224 is setwith an AID of each unlocked contactless transaction application. Whenthere is a change in the status of any transaction application (changingfrom locked to unlocked or vice versa), the DTC 12 is operable to repeatthe process of setting the PSE selection application 222 with an AID ofeach unlocked contact transaction application and setting the PPSEselection application 224 with an AID of each unlocked contacttransaction application.

Although the presently described embodiment of the application selectionmodule 225 includes the PSE selection application 222 and the PPSEselection application 224, the application selection module 225 is notlimited to these selection applications. For example, the applicationselection module 225 can include a selection application for selecting atransaction application associated with a non-payment personality. Sucha selection application can operate in a similar way to the PSE and PPSEselection applications.

In DTCs in the prior art, the PSE selection application and PPSEselection application are set in the factory and never changed once theDTC is in the field. There is no facility to re-set the PSE selectionapplication and PPSE selection application once the DTC is in the field.

In an embodiment of the present invention, the DTC 12 is operable to setor re-set the PSE selection application 222 and the PPSE selectionapplication 224 by sending at least one script 203 containing one morecommands (script 203 is shown in FIG. 6) to the application selectionmodule 225 in the DTPU 30. In an embodiment, the script 203 includesappropriately authenticated APDUs which include an encrypted payload inaccordance with the SCP02 protocol. For security purposes, the script203 must be authenticated as a prerequisite to being executed by theapplication selection module 225. The script 203 is authenticatedagainst the SSD 96 (which, in the hierarchy in FIG. 6, is a parent tothe application selection module 225) and executed by the PSE selectionapplication 222 and/or PPSE selection application 224. The script 203,when executed, sets the PSE selection application with an AID of eachunlocked contact transaction application, and sets the PPSE selectionapplication 224 with an AID of each unlocked contactless transactionapplication.

In an embodiment, the script 203 is generated on the DTC 12 by thescript applet 81 (in the OSE 80). Inputs used by the script applet 81 togenerate the script include: a script template provided by the templatestore 82 (in the OSE 80), an AID of each unlocked transactionapplication (each AID is provided by the MCU 32, for example frommetadata shown in FIG. 2), a key 104 (stored in the OSE 80), and acounter value associated with a targeted SCP02 keyset in the DTPU 30.The key 104 is a copy of a key held by SSD 96. As shown in FIG. 6, SSD96 is a parent to the application selection module 225 in the securityhierarchy. The script applet 81 uses the key 104 and counter value togenerate a session key which is used to authenticate the script 203against the SSD 96 so that the script can be executed by the applicationselection module 225. An example of a process for generating the script203 is described below with reference to FIGS. 10 and 11, as part of aprocess for changing the active personality/personalities.

In an alternative embodiment, script 203 is provided by the provisioninginfrastructure 10 (shown in FIG. 5) in a provisioning process. Anembodiment of a provisioning infrastructure 10 operable suitable forprovisioning the DTC 12 while the DTC 12 is in the field (remote fromthe provisioning infrastructure 10) is described below with reference toFIGS. 18-20. In an embodiment, script 203 is provided by theprovisioning infrastructure 10 (specifically the DPD manager 36) andstored in the MCU 32 until required. In another embodiment, script 203is stored in the OSE 80 and retrieved by the MCU 32 when required. Inanother embodiment, script 203 is stored in the secure memory 84 andretrieved by the MCU 32 when required. Multiple types of scripts 203 canbe provisioned and stored to meet the future requirements of the DTC 12until it is provisioned by the provisioning infrastructure 10.

In an alternative embodiment, script 203 is pre-provisioned (installedwhile the DTC 12 is in the factory) and stored until required. Again,such script 203 can be stored in the MCU 32, OSE 80 or secure memory 84until required. In such an embodiment, multiple scripts 203 are storedto meet the future requirements of the DTC 12 or until it is provisionedby a provisioning infrastructure 10.

In an embodiment, script 203 includes each AID to be set. In analternative embodiment, the PSE selection application 222 and/or thePPSE selection application 224 includes a register which is operable tostore AIDs of respective transaction applications hosted by the DTPU 30.In such an embodiment, script 203 includes information to identify atransaction application (for example, “05” to indicate a specifictransaction application), and the PSE selection application 222 and/orthe PPSE selection application 224 refer to the register to look up theAID corresponding to transaction application “05”. When a newpersonality is installed on the DTC, the register is updated with eachAID associated with the new personality.

De-Activating PDTPs

In an embodiment, changing the active personality on the DTC involveslocking all transaction applications hosted by the DTPU and thenunlocking each transaction application associated with a selected PDTP,which leaves any other transaction application locked. Each lockedtransaction application is inoperable during a transaction and cannot bedirectly selected by a DTD.

In an embodiment of a locking process illustrated in FIG. 7 (which showsthe same hierarchy 201 depicted in FIG. 6), SSD 206 is targeted with anappropriately authenticated “Lock and Associated” command, which doesthe following:

-   -   a) locks (makes inactive) SSD 206,    -   b) locks all SSDs associated with (children of) the SSD 206 in        the hierarchy, and    -   c) locks all transaction applications associated with (children        of) the locked SSDs.

Therefore, in this embodiment, the Lock and Associated command has theeffect of a) locking SSD 206, b) locking SSDs 228, 236, 242, 244, 246,248, 250, and c) de-activating PDTPs 230, 232, 234, 238, 240. Eachpadlock 211 indicates either a locked SSD or an inoperable PDTP.

The locking of all SSDs associated with SSD 206 (and the consequentde-activation of all PDTPs) is referred to here as a “cascade locking”process. In a cascade locking process the SSD 206 is referred to as aLock SSD for PDTPs. Applying cascade locking to Lock SSD 206 makes allPDTPs inoperable. From the cardholder's point of view, cascade lockingde-activates all personalities (makes them inoperable). In anembodiment, the DTC is operable to perform cascade locking when changingthe active personality on the DTC.

The cascade locking process is triggered when the DTPU receives at leastone authenticated script 207 in the form of APDUs. In an embodiment, theAPDUs include an encrypted payload in accordance with the SCP02 protocoland are authenticated against SSD 96 (the parent SSD of applicationselection module 225).

In this example, script 207 commands the application selection module225 to target the Lock SSD 206 (as indicated by arrow 209) with acascade locking command. In an embodiment, the application selectionmodule 225 is operable to use the Global Lock privilege to target theLock SSD 206 with the cascade locking command.

In an embodiment, script 207 targets the PSE selection application 222to perform the cascade locking process. In an alternative embodiment,the script 207 targets the PPSE selection application 224 to perform thecascade locking process. In an alternative embodiment, the script 207targets a different unlocked application to either perform the cascadelocking process or delegate the PSE or PPSE application to perform thecascade locking process.

In an alternative embodiment (not shown), a single cascade lockingcommand is not used to de-activate PDTPs. Instead, multiple lower-levelSSDs are each targeted with a separate lock command. For example, bylocking SSD 228 and SSD 236, all lower level SSDs will be locked. In theexample shown in FIG. 7, targeting SSD 228 with a lock command causesSSDs 242, 244, 246 to be locked and PDTPs 230, 232, 234 to bede-activated. Similarly, targeting SSD 236 with a lock command causesSSDs 248, 250 to be locked and PDTPs 238, 240 to be de-activated.Alternatively, a separate lock command can be targeted at each of SSDs242, 244, 246, 248, 250 to de-activate all PDTPs. In one version, theapplication selection module 225 uses the Global Lock privilege totarget each SSD to be locked. In another version, Global Lock privilegeand the application selection module 225 are not used. Instead, each SSDto be locked (for example SSD 242) is targeted directly by a lockcommand included in a script provided to the DTPU 30. The script is inthe form of APDUs and authenticated against the SSD to be targeted. Inan embodiment, a registry in the MCU keeps a record of the lockingstatus of each SSD and enables the DTC 12 to avoid generating scriptsfor SSDs that do not need to change locking status.

In an embodiment, each authenticated script to lock all PDTPs (such asscript 207) is generated on the DTC 12. In an embodiment, the MCU 32commands the script applet 81 (in the OSE 80) to generate eachauthenticated script. Inputs used by the script applet 81 to generatethe script include: a script template (provided by the template store 82in the OSE 80), identifiers such as AIDs to identify each PDTP to bede-activated (the identifiers are included in metadata provided by theMCU 32), a key 104 (stored in the OSE 80), and a counter valueassociated with a targeted SCP02 keyset in the DTPU 30. The key 104 is acopy of a key held by the SSD to be targeted. Where the script targetsthe application selection module 225, the key a copy of a key held bythe parent SSD 96. An example of a process for generating script 207 isdescribed below with reference to FIGS. 10 and 11. Where the scripttargets a parent SSD of a PDTP, the key 104 is a copy of a key held bythe targeted SSD.

The script applet 81 uses the key 104 and counter value to generate asession key which is used to authenticate the script against thetargeted SSD. Once an authenticated script has been generated by thescript applet 81, the MCU 32 forwards the authenticated script to theDTPU 30 for execution.

Activating Targeted PDTPs

In an embodiment, changing the active personality on the DTC includesactivating a targeted PDTP. Activating a targeted PDTP directly after acascade locking process results in only the targeted PDTP being active.Therefore, only the personality associated with the targeted PDTP isactivated. Referring to FIG. 8 (which shows the same hierarchy 201depicted in FIGS. 6 and 7), an inoperable PDTP can be activated byunlocking at least one transaction application associated with the PDTP.For example, PDTP 230 can be activated by unlocking at least onetransaction application associated with PDTP 230.

In this example, script 213 commands the application selection module225 (which has the Global Lock privilege) to target at least onetransaction application associated with the Visa PDTP 230 with anapplication unlock command (as indicated by arrow 215). In anembodiment, the application unlock command is a SET STATUS command whichcauses one or more transaction applications associated with the VisaPDTP 230 to revert to their previous state, which was an unlocked state.Once script 213 is executed, Visa PDTP 230 becomes active, which meanstransaction applications associated with PDTP 230 can be used intransactions and the personality associated with PDTP 230 is active(available to be used by the cardholder).

In an alternative embodiment, the script 213 targets a differentunlocked application on the DTPU 30 (instead of application selectionmodule 225) to either target each transaction application with an unlockcommand, or delegate the PSE or PPSE application to target eachtransaction application with an unlock command.

In a further alternative embodiment (not shown), Global Lock privilegeand the application selection module 225 are not used. Instead, a scriptis provided to the DTPU 30 to command another application on the DTPU 30to target each PDTP to be activated. Such an application could be anunlocked SSD. In an embodiment, an additional SSD referred to here as anApplication Unlock SSD is provided which is a parent to SSD 206 for thepurpose of activating PDTPs. The Application Unlock SSD does not getlocked in a cascade locking process because it is a parent to Lock SSD206 in the hierarchy. In the example shown in FIG. 8, a script would beprovided to command the Application Unlock SSD to activate PDTP 230,without involving the application selection module 225 in the unlockingprocess.

In an embodiment, each authenticated script for activating a PDTP (suchas script 213) is generated on the DTC 12. In an embodiment, the MCU 32commands the script applet 81 (in the OSE 80) to generate eachauthenticated script. Inputs used by the script applet 81 to generatethe script include: a script template (provided by the template store 82in the OSE 80), identifiers such as AIDs to identify each PDTP to beactivated (identifiers are included in metadata provided by the MCU 32),a key 104 (stored in the OSE 80), and a counter value associated with atargeted SCP02 keyset in the DTPU 30. The key 104 is a copy of a keyheld by the SSD to be targeted. Where the script targets the applicationselection module 225, the key 104 is a copy of a key held by the parentSSD 96. An example of such a process for generating script 213 isdescribed below with reference to FIGS. 10 and 11. Where the scripttargets a parent SSD of PDTP, the key 104 is a copy of a key held by theparent SSD (for example, where the script targets PDTP 230, the key is acopy of the key held by SSD 242).

The script applet 81 uses the key 104 and counter value to generate asession key which is used to authenticate the script against thetargeted SSD. Once an authenticated script has been generated by thescript applet 81, the MCU 32 forwards the authenticated script to theDTPU 30 for execution.

Script 213 may be included as part of the cascade locking script 207 orit may be a separate script. In this embodiment, script 213 targets aPDTP 230 which may include both contact and/or contactlessfunctionality. Script 213 is operable to target a single transactionapplication or multiple transaction applications within a PDTP, forexample either a contact transaction application or contactlesstransaction application, or both contact and contactless transactionapplications.

The PSE selection application 222 and PPSE selection application 224 areeach operable to unlock any transaction application on the DTPU. In anembodiment, the PSE selection application 222 is used to unlock eachcontact transaction application within a targeted PDTP, and the PPSEselection application 224 is used to unlock each contactless transactionapplication within a targeted PDTP. In an embodiment, the PSE selectionapplication 222 is operable to manage the PPSE selection application 224(to reduce processing overheads). In such an embodiment, script 213targets the PSE selection application 222, which delegates the PPSEselection application 224 to unlock any contactless applications to betargeted. In another embodiment, the PPSE selection application 224 isoperable to manage the PSE selection application 222. In such anembodiment, script 213 targets the PPSE selection application 222 whichdelegates the PSE selection application 222 to unlock any contactapplications to be targeted. In an alternative embodiment, there is anadditional application (not shown, but which is part of the applicationselection module 225) which manages both the PSE and PPSE selectionapplications 222, 224. In such an embodiment, script 213 targets thisadditional application, which delegates the PSE and PPSE selectionapplications 222, 224 to unlock transaction applications to be targetedas appropriate.

Unlocking a Targeted Transaction Application

In an embodiment, the process for unlocking a targeted transactionapplication is the same as the process described above for activating atargeted PDTP, except an individual transaction application is targetedinstead of a group of transaction applications associated with a PDTP.Unlocking a targeted transaction application directly after a cascadelocking process results in only the targeted transaction applicationbeing selectable in a transaction.

Multiple Transaction Types Associated with a PersonalityThe security hierarchy embodiment depicted in FIGS. 6-8 show PDTPswithout showing the associated transaction applications. FIG. 9A showsan embodiment of a portion of a security hierarchy in which fourtransaction applications 370, 371, 372, 373 are associated with an SSD242, without showing the other parts of the hierarchy. Together, thefour transaction applications 370, 371, 372, 373 make up PDTP 230 (shownin FIG. 6) which is associated with a single personality, namely a Visacredit account personality issued by Bank 1. The four transactionapplications have the following characteristics:

-   -   transaction application 370: operates in contact mode,        transaction type is US dollars, identifying information is        sequence number 10    -   transaction application 371: operates in contactless mode,        transaction type is US dollars, identifying information is        sequence number 10    -   transaction application 372: operates in contact mode,        transaction type is Pound sterling, identifying information is        sequence number 11    -   transaction application 373: operates in contactless mode,        transaction type is Pound sterling, identifying information is        sequence number 11.

When the DTC 12 conducts a transaction with a DTD 70, the DTC isoperable to communicate certain transaction information to the DTD 70which can include identifying information indicative of the transactionapplication used in the transaction. In this embodiment, the identifyinginformation is a primary PAN and a sequence number. Since the primaryPAN is the same for all transaction applications 370, 371, 372, 373, thesequence number distinguishes transaction applications 370, 371 fromtransaction applications 372, 373. As is known in the art, thetransaction information is transmitted to the issuer 18 or an agent viaa payment network which typically includes an acquirer 72 and a paymentscheme 74. Thus, the sequence number can be transmitted to theissuer/agent as part of the transaction information, which enables theissuer/agent to distinguish payments made with transaction applications370, 371 from payments made with transaction applications 372, 373.

Once the issuer 18 receives the transaction information (including theidentifying information) the issuer is operable to correlate thereceived identifying information (the sequence number) with atransaction type which in this embodiment indicates the currency used(either US dollars or Pounds sterling). In an embodiment, the issuer isoperable to provide a record of transactions to the cardholder and toinclude the transaction type for each transaction. The cardholder mayuse the record of transactions to categorise expenses incurred with theVisa credit account personality. In this way, the cardholder can seewhich currency was used for each transaction with the personality (Visacredit account issued by Bank 1).

Although the identifying information in this embodiment is a sequencenumber, it will be understood that other types of identifyinginformation capable of being transmitted to an issuer can be usedinstead of the sequence number, for example: an AID of the transactionapplication used in the transaction, a PAN associated with thetransaction application, or a tokenised PAN associated with thetransaction application.

In an embodiment, the DTC 12 is operable to enable the cardholder toselect a group of transaction applications, for example either a firstgroup 370 and 371, or a second group 372 and 373, prior to conducting atransaction with a DTD 70. The DTD then selects a transactionapplication from within the cardholder's selected group of transactionapplications, and in this case the selection is based on whether thetransaction is contact or contactless. In another embodiment, the DTC 12is operable to enable the cardholder to select a specific transactionapplication (not a group of transaction applications), which gives thecardholder more control over the kinds of transactions that can beperformed with the DTC 12.

In another embodiment, the DTC 12 is operable to request the cardholderto select a category of transaction application, which may simplify theselection process for cardholders. One example of a category is thecurrency in which the transaction application operates. The DTC canrequest the cardholder to select either a first category (for example,US dollars transaction applications) or a second a category (forexample, Pound sterling transaction applications). Another example of acategory is based on the operation mode of the DTC. The DTC can requestthe cardholder to select either a first category (for example, contacttransaction applications) or a second category (for example, contactlesstransaction applications).

When the cardholder selects a transaction application category, the DTC12 is limited to using a transaction application from within thatcategory. If there are multiple transaction applications in a category,the selection may be made by the DTC or the DTD. In an embodiment, theDTC 12 is operable to make a default selection of a transactionapplication in the event that the cardholder does not wish to make aselection.

In an alternative embodiment, the DTC 12 is operable to detect ageolocation in which the transaction is about to take place and toautomatically select, on behalf of the cardholder, a transactionapplication with a suitable currency. Such a selection can be based on arule stored in the DTC, for example: “if the DTC is within the UK, usePounds sterling, otherwise use US dollars”. In an embodiment, such arule is input into the DTC by the cardholder. In another embodiment, therule is stored in the DTC before the DTC is distributed to thecardholder. In another embodiment, the rule is provisioned to the DTC bythe provisioning infrastructure 10 while the DTC is in the field.

FIG. 9B shows another embodiment of a portion of a security hierarchy inwhich ten transaction applications 375 to 384 are associated with an SSD242. Together, the ten transaction applications 375 to 384 make up aPDTP 230 (shown in FIG. 6) which is associated with a singlepersonality, namely a Visa credit account personality issued by Bank 1.The ten transaction applications have the following characteristics:

-   -   transaction application 375: operates in contact mode,        identifying information is sequence number 10    -   transaction application 376: operates in contactless mode,        identifying information is sequence number 10    -   transaction application 377: operates in contact mode,        identifying information is sequence number 11    -   transaction application 378: operates in contactless mode,        identifying information is sequence number 11    -   transaction application 379: operates in contact mode,        identifying information is sequence number 12    -   transaction application 380: operates in contactless mode,        identifying information is sequence number 12    -   transaction application 381: operates in contact mode,        identifying information is sequence number 13    -   transaction application 382: operates in contactless mode,        identifying information is sequence number 13    -   transaction application 383: operates in contact mode,        identifying information is sequence number 14    -   transaction application 384: operates in contactless mode,        identifying information is sequence number 14.

In this embodiment, the identifying information included in thetransaction information is a sequence number. The transactioninformation is transmitted to the issuer 18 via the payment network. Inan embodiment, the issuer 18 or an agent is operable to correlate thesequence number with a transaction type, for example: sequence number10=type 1, sequence number 11=type 2, sequence number 12=type 3,sequence number 13=type 4, sequence number 14=type 5. The issuer is alsooperable to provide a record of transactions to the cardholder and toinclude the transaction type for each transaction. In an embodiment, theissuer/agent is operable to receive, from the cardholder, descriptivenames of each transaction type, and to include the descriptive names ina record of transactions issued to the cardholder. For example, acardholder might assign descriptive names based on the type of expense,such as “entertainment” for type 1, “household supplies” for type 2,“home maintenance” for type 3, “work expenses” for type 4, and “other”for type 5. Alternatively, the issuer can be operable to assign atransaction type and descriptive name based on characteristics of thetransaction, for example the type of vendor or other information,without input from the cardholder.

Many other transaction types can be used, for example: expense type,budget category, location, currency, project, or person or organisationbenefiting from the expense. Any number of transaction types can beused, depending on the number of transaction applications installed onthe DTC.

Other types of identifying information capable of being transmitted toan issuer can be used instead of the sequence number, for example an AIDof the transaction application used in the transaction, a PAN associatedwith the transaction application, or a tokenised PAN associated with thetransaction application.

In another embodiment (not illustrated), which is a variation on theembodiment shown in FIG. 9B, an additional ten transaction applicationsare associated with SSD 242 as well as the ten transaction applications375 to 384, making a total of twenty transaction applications. Theadditional ten transaction applications are provided for use in aninternational payment network, and the ten transaction applications 375to 384 are provided for use in a domestic payment network. Theadditional ten transaction applications have a primary PAN which isdifferent from that of the ten transaction applications 375 to 384. Theadditional ten transaction applications have the same respectivesequence number and the same respective operation mode(contact/contactless) as the ten transaction applications 375 to 384.

Multiple Tokenised PANs Associated with a Personality

FIG. 9C shows another embodiment of a portion of a security hierarchy inwhich ten transaction applications 386 to 395 are associated with SSD242. Together, the ten transaction applications 386 to 395 make up asingle PDTP 230 which is associated with a single personality, namely aVisa credit account personality issued by Bank 1. In this embodiment,all ten transaction applications are dual interface and thereforeoperate in both contact and contactless modes. The ten transactionapplications have the following characteristics:

-   -   transaction application 386: identifying information is        tokenised PAN 1    -   transaction application 387: identifying information is        tokenised PAN 2    -   transaction application 388: identifying information is        tokenised PAN 3    -   transaction application 389: identifying information is        tokenised PAN 4    -   transaction application 390: identifying information is        tokenised PAN 5    -   transaction application 391: identifying information is        tokenised PAN 6    -   transaction application 392: identifying information is        tokenised PAN 7    -   transaction application 393: identifying information is        tokenised PAN 8    -   transaction application 394: identifying information is        tokenised PAN 9    -   transaction application 395: identifying information is        tokenised PAN 10.

Transaction applications 386 to 395 each use a different tokenised PAN.For security purposes, this embodiment enables transactions to beperformed with ten different versions of identifying information, whichin this embodiment is a tokenised PAN. By providing the option to useten different tokenised PANs, the cardholder can avoid consistentlyusing the same tokenised PAN, which may reduce the risk of fraud. Whenthe DTC 12 conducts a transaction with a DTD 70, the DTC is operable tocommunicate to the DTD the tokenised PAN as part of the transactioninformation and the transaction information is transmitted to the issuer18 via the payment network.

In an embodiment, the DTC includes a selection algorithm which selectsone of the transaction applications to be used in a transaction. In anembodiment, the algorithm re-selects a transaction application afterevery transaction. In an embodiment, the algorithm re-selects atransaction application after every second transaction. In anembodiment, the selection algorithm is a random or pseudo randomselection algorithm. In another embodiment, the selection algorithmcycles through transaction applications. Many other algorithms arepossible. In an alternative embodiment, the DTC is operable to enablethe cardholder to select the transaction application to be used.

It will be understood that other hierarchical structures could be usedinstead of the hierarchies shown in FIGS. 9A-9C. For example, in FIG.9A, transaction applications 370-373 do not necessarily need to beassociated with the same SSD. In an alternative hierarchy (not shown),each transaction application 370-373 is associated with a separate SSD.Many other variations are possible.

Sequence Diagrams for Adopting a Personality while in the Field

FIGS. 10-11 illustrate an embodiment of a process which enables acardholder of the DTC, while in the field, to select and activate one ormore of a plurality of personalities installed on the DTC without theDTC communicating with a provisioning infrastructure 10 or provisioningnetwork 16. The process in FIG. 10 contains sub-process 920 which isillustrated in FIG. 11.

Referring to FIG. 10, the process for selecting and activating apersonality begins in step 900 when a cardholder 674 uses the displayscreen 83A (FIG. 1A) to browse the personalities currently installed onthe DTC. The available personalities are represented on the displayscreen 83A by one or more items of metadata associated with eachpersonality. An embodiment of metadata associated with a personality isshown in FIG. 2. In an embodiment, the metadata displayed on the displayscreen 83A is the payment scheme name, bank name and last four digits ofthe PAN, and logo for the payment scheme (the logo is not included inthe embodiment of metadata shown in FIG. 2).

In step 902, the cardholder 674 selects one (or more) personality to beactivated and the selection is recorded by the MCU 32. In thisembodiment, the DTC 12 is operable to simultaneously have multipleactive personalities. The MCU registry stores rules regarding whichpersonalities are permitted to be simultaneously active, and the MCUrefers to these rules before proceeding with a personality change. Ifthe rules do not permit the requested personality change, the MCU 32displays a message on the graphical display screen 83A to indicate thatthe personality change cannot proceed. In another embodiment, when acardholder requests a new personality to be activated, the DTC 12 isoperable to de-activate any other personality that the rules do notpermit to be simultaneously active with the selected personality. Insuch an embodiment, the MCU 32 can be operable to request confirmationfrom the cardholder before proceeding to de-activate a personality. Inanother embodiment, the rules specify that only one personality can beactive at any time.

In step 904, if the rules permit the requested personality change, theMCU 32 looks up the metadata stored in MCU registry 35 and identifiesthe metadata associated with each selected personality. The metadata foreach personality contains AID information which specifies an AID foreach transaction application of a PDTP associated with each selectedpersonality. The MCU 32 uses the metadata to generate a list of AIDsassociated with each selected personality.

In step 906, the MCU 32 sends a command (which contains the list of AIDsfor the selected personality) to the script applet 81 to generate atleast one script which, when executed by the application selectionmodule 225 on the DTPU 30: de-activates all PDTPs on the DTPU, activatesa PDTP associated with the selected personality, and sets theapplication selection module 225 with AIDs for the selected personality.The script generated in step 906 is equivalent to three scriptsdescribed earlier: script 207 shown in FIG. 7 (for cascade locking),script 213 shown in FIG. 8 for (targeted unlocking), and script 203shown in FIG. 6 (for setting AIDs on the application selection module225).

In step 908, the script applet 81 requests a script template from thetemplate store 82 (which is stored on the OSE), and in step 910 thetemplate store 82 returns the requested script template to the scriptapplet 81. In step 912, the script applet 81 fills the script templatewith values to create a script. The created script is in the form ofAPDUs and derived from: AIDs for contact transaction applicationsassociated with the selected PDTP(s), and AIDs for contactlesstransaction applications associated with the selected PDTP(s).

In step 914, the script applet 81 generates a session key using SSD key104 (which is stored in the OSE 80), and a counter value associated witha targeted SCP02 keyset in the DTPU 30. The SSD key 104 stored in theOSE 80 is a copy of a key held by SSD 96 in the DTPU 30. As shown inFIGS. 7-8, the SSD 96 is a parent to the application selection module225 in the security hierarchy. The purpose of the session key is toauthenticate the script against the SSD 96 so that the script can beexecuted by the application selection module 225. The script applet 81uses the session key to encrypt the payloads of the APDUs, for examplein accordance with SCP02.

In step 916, the script applet 81 forwards the authenticated script tothe MCU 32, which in step 918 forwards the authenticated script to theapplication selection module 225 in the DTPU. The next steps(sub-process 920) occur on the DTPU and are shown in FIG. 11.

Referring to FIG. 11, in step 948 the authenticated script isauthenticated against SSD 96. In step 950, the script is passed to thePSE selection application 222 which is part of the application selectionmodule 225. In step 952, the PSE selection application 222 usesGlobalPlatform Global lock privilege to execute a “Lock and Associated”command (as shown in FIG. 7) against the Lock SSD 206 which causes allPDTPs on the DTPU to be inoperable. In step 954, there is anacknowledgement that the Lock SSD 206 has been locked.

Steps 958 and 960 are a loop 956 in which the PSE selection application222 processes the script (generated in steps 912, 914), reads the AIDsfor contact transaction applications, and uses GlobalPlatform Globallock privilege to unlock (as shown in FIG. 8) each contact transactionapplication 940 associated with the AIDs. Step 960 is an acknowledgementof each transaction application 940 being unlocked. The loop 956 repeatsuntil all contact transaction applications associated with AIDs in thescript are unlocked.

Steps 964 and 966 are a loop 962 in which the PSE selection application222 processes the script (generated in steps 912, 914), reads the AIDsfor contactless transaction applications, and uses GlobalPlatform Globallock privilege to unlock (as shown in FIG. 8) each contactlesstransaction application 942 associated with the AIDs. Step 966 is anacknowledgement of each transaction application 940 being unlocked. Theloop 962 repeats until all contactless transaction applicationsassociated with AIDs in the script are unlocked.

In step 968, if the list of AIDs for contact transaction applications isempty, then the PSE selection application 222 is disabled. Otherwise, ifthe list of AIDs for contact transaction applications is not empty, thenin step 770 the PSE selection application 222 is set with the AIDs ofcontact transaction applications that have been successfully unlocked(as shown in FIG. 6).

In step 972, the PSE selection application 222 initiates an update ofthe PPSE selection application 224. In step 974, if the list of AIDs forcontactless transaction applications is empty, then the PPSE selectionapplication 224 is disabled. Otherwise, if the list of AIDs for contacttransaction applications is not empty, then in step 976 the PPSEselection application 224 is set with the AIDs of contactlesstransaction applications that have been successfully unlocked. In step978, an acknowledgement is returned to the PSE selection application222.

In step 980, the PSE selection application 222 uses GlobalPlatformGlobal lock privilege to unlock the Lock SSD 206, and in step 982 anacknowledgement is returned to the PSE selection application 222.

Referring to FIG. 10, the process continues with step 922 in which theapplication selection module 225 sends an acknowledgement (in the formof R-APDUs) to the MCU 32. In step 924, the MCU 32 checks the statuswords (also called status bytes) in the R-APDUs. If an error occurs thatrequires action by the cardholder, the MCU 32 displays an appropriateerror message on the display screen 83A. In step 926, if the statuswords do not indicate an error, the MCU 32 updates the MCU registry 35(not shown in FIG. 10) with the activation states of AIDs for contactand contactless transaction applications. In step 928, the MCU 32updates the display screen 83A with information to indicate that the newpersonality has been activated. Finally, in step 930, the cardholderchecks the display to confirm that the new personality has beenactivated as expected.

Sequence Diagrams for Adopting a Transaction Application while in theField

Referring again to FIGS. 10-11, an embodiment of a process for selectingand adopting at least one transaction application from a plurality oftransaction applications associated with a personality will now bedescribed. The steps are the same as for adopting a personalitydescribed above, but apply to individual transaction applicationsinstead of PDTPs.

Referring to FIG. 10, the process for selecting and activating atransaction application begins in step 900 when a cardholder 674 usesthe graphical user interface 83A, 83B (FIG. 1A) to browse transactionapplications currently installed on the DTC for a selected personality.The available transaction applications are represented on the displayscreen 83A by one or more items of metadata associated with eachpersonality. In an embodiment, the metadata displayed on the displayscreen 83A is the transaction type, payment scheme name, bank name, lastfour digits of the PAN, and logo for the payment scheme. Examples oftransaction types include currency, expense type, budget category,location, project, or person or organisation benefiting from theexpense. The transaction type may have been defined by the cardholder.

In step 902, the cardholder 674 selects one or more transactionapplication to be unlocked and the selection is recorded by the MCU 32.In this embodiment, the DTC 12 is operable to simultaneously havemultiple unlocked transaction applications. The MCU registry storesrules regarding which transaction applications are permitted to besimultaneously unlocked, and the MCU refers to these rules beforeproceeding to unlock transaction applications. If the rules do notpermit the requested unlocking of transaction applications, the MCUdisplays a message on the display screen 83A to indicate that therequest cannot proceed.

In step 904, if the rules permit the requested unlocking of one or moretransaction applications, the MCU 32 looks up the metadata stored in MCUregistry 35 and identifies the metadata associated with each selectedtransaction application. The metadata contains an AID for with eachselected transaction application. The MCU 32 uses the metadata togenerate a list of AIDs associated with the selected transactionapplication(s).

In step 906, the MCU 32 sends a command (which contains the AID for eachselected transaction application) to the script applet 81 to generate ascript (which includes at least one command) which, when executed on theDTPU, locks all transaction applications on the DTPU and then unlockseach selected transaction application as described above with referenceto the security hierarchy in FIGS. 7-8. In step 908, the script applet81 requests a script template from a template store 82 (which is storedon the OSE), and in step 910 the template store 82 returns the requestedscript template to the script applet 81. In step 912, the script applet81 fills the script template with values to create a script. The createdscript is in the form of APDUs and derived from an AID for each selectedcontact transaction application, and an AID for each selectedcontactless transaction application.

In step 914, the script applet 81 generates a session key using SSD key104 (stored in the OSE 80, as shown in FIG. 1B) and a counter valueassociated with a targeted SCP02 keyset in the DTPU 30, and uses thesession key to encrypt the payloads of the APDUs, for example inaccordance with SCP02. The purpose of the session key is to authenticatethe script against the application selection module 225. The SSD keystored in the OSE 80 is a copy of a key held by the SSD 96 associatedwith the application selection module 225 in the DTPU 30. In step 916,the script applet 81 forwards the script to the MCU 32, which forwardsthe script (in step 918) to the application selection module 225 in theDTPU. The next steps (sub-process 920) occur on the DTPU and are shownin FIG. 11.

Referring to FIG. 11, in step 948 the script is authenticated againstthe SSD 96 of the application selection module 225. In step 950, thescript is passed to the PSE selection application 222 which is part ofthe application selection module 225. In step 952, the PSE selectionapplication 222 uses GlobalPlatform Global lock privilege to execute a“Lock and Associated” command against the Lock SSD 206 (an example of aLock SSD 206 is shown in FIGS. 6-8) which causes all transactionapplications on the DTPU to be locked. In step 954, there is anacknowledgement that the Lock SSD 206 has been locked.

Steps 958 and 960 are a loop 956 in which the PSE selection application222 processes the script (generated in steps 912, 914), reads the AIDsfor contact transaction applications, and uses GlobalPlatform Globallock privilege to unlock each contact transaction application 940associated with the AIDs. Step 960 is an acknowledgement of eachtransaction application 940 being unlocked. The loop 956 repeats untilall contact transaction applications associated with AIDs in the scriptare unlocked.

Steps 964 and 966 are a loop 962 in which the PSE selection application222 processes the script (generated in steps 912, 914), reads the AIDsfor contactless transaction applications, and uses GlobalPlatform Globallock privilege to unlock each contactless transaction application 942associated with the AIDs. Step 966 is an acknowledgement of eachtransaction application 940 being unlocked. The loop 962 repeats untilall contactless transaction applications associated with AIDs in thescript are unlocked.

In step 968, if the list of AIDs for contact transaction applications isempty, then the PSE selection application 222 is disabled. Otherwise, ifthe list of AIDs for contact transaction applications is not empty, thenin step 770 the PSE selection application 222 is set with the AIDs ofcontact transaction applications that have been successfully unlocked.

In step 972, the PSE selection application 222 initiates an update ofthe PPSE selection application 224. In step 974, if the list of AIDs forcontactless transaction applications is empty, then the PPSE selectionapplication 224 is disabled. Otherwise, if the list of AIDs for contacttransaction applications is not empty, then in step 976 the PPSEselection application 224 is set with the AIDs of contactlesstransaction applications that have been successfully unlocked. In step978, an acknowledgement is returned to the PSE selection application222.

In step 980, the PSE selection application 222 uses GlobalPlatformGlobal lock privilege to unlock the Lock SSD 206, and in step 982 anacknowledgement is returned to the PSE selection application 222.

Referring to FIG. 10, the process continues with step 922 in which theapplication selection module 225 sends an acknowledgement (in the formof R-APDUs) to the MCU 32. In step 924, the MCU 32 checks the statuswords (also called status bytes) in the R-APDUs. If an error occurs thatrequires action by the cardholder, the MCU 32 displays an appropriateerror message on the display screen 83A. In step 926, if the statuswords do not indicate an error, the MCU 32 updates the MCU registry 35(not shown in FIG. 10) with the activation states of AIDs for contactand contactless transaction applications. In step 928, the MCU 32updates the display screen 83A with information to indicate that eachselected transaction application has been activated. Finally, in step930, the cardholder checks the display to confirm the activation is asexpected.

Further Embodiments of a Security Hierarchy on the DTPU

FIG. 12 illustrates another embodiment of a security hierarchy 241suitable for hosting a plurality of personalities and for adopting apersonality from the plurality of personalities while the DTC is in thefield. Where the features are the same as those in FIG. 6, the samereference numerals have been used. In the embodiment in FIG. 12, Bank 1has only one SSD 228, and this SSD is a parent to three PDTPs (230, 232,234). Bank 2 also has only one SSD 236 which is a parent to two PDTPs(238, 240). This embodiment has fewer SSDs than in FIG. 6 but the PDTPscan be locked and unlocked using the same process illustrated in FIGS.7-8. Cascade locking of the Lock SSD 206 causes all associated SSDs(228, 236) to be locked, and all associated PDTPs (230, 232, 234, 238,240) to be inoperable. The application selection module 225 is operableto activate a targeted PDTP as described above with reference to FIGS.7-8.

FIG. 13 illustrates another embodiment of a security hierarchy 251suitable for hosting a plurality of personalities and for adopting apersonality from the plurality of personalities while the DTC is in thefield. In this embodiment, the PDTPs and associated SSDs are arranged ina flatter hierarchy than in the embodiments in FIGS. 6-8 and 12. EachPDTP is a child of an SSD which is a child of the Lock SSD 206 in thesecurity hierarchy. “Bank 1” has three SSDs 252, 254, 256 are associatedwith (or are “children” of) Lock SSD 206 and “Bank 2” has two SSDS 258,260 which are associated with the Lock SSD 206. Bank 1 and Bank 2 wouldeach use their own SP-TSM to perform operations on the DTPU.

Each SSD of Bank 1 is a parent to a single PDTP 262, 264, 266 and eachSSD of Bank 2 is a parent to a single PDTP 268, 270. Cascade locking (ofthe Lock SSD 206) causes all child SSDs (252, 254, 256, 258, 260) to belocked, and all associated PDTPs (262, 264, 266, 268, 270) to beinoperable. The application selection module 225 is operable to activatea targeted PDTP as described above with reference to FIGS. 7-8.

FIG. 14 illustrates another embodiment of a security hierarchy 281suitable for hosting a plurality of personalities and for adopting apersonality from the plurality of personalities while the DTC is in thefield. In this embodiment, the DTC hosts seven personalities associatedwith three banks (Bank 1, Bank 2, Bank 3) and three payment schemes(Visa, Mastercard, American Express) and each bank uses the services ofa TSP to perform operations on the DTPU:

-   -   a TSP for Visa accounts has control of SSD 280 and associated        SSDs (286, 290, 294) and associated PDTPs (288, 292, 296);    -   a TSP for Mastercard accounts has control of SSD 282 and        associated SSDs (298, 302) and associated PDTPs (300, 304); and    -   a TSP for American Express accounts has control of SSD 284 and        associated SSDs (306, 310) and associated PDTPs (308, 312).

As in the embodiments shown in FIGS. 6-8 and 12-13, cascade locking ofthe Lock SSD 206 in FIG. 14 causes all associated SSDs (280, 286, 290,294, 282, 298, 302, 284, 306, 310) to be locked, and all associatedPDTPs (288, 292, 296, 300, 304, 308, 312) to be inoperable. Theapplication selection module 225 in FIG. 14 is operable to activate atargeted PDTP as described above with reference to FIGS. 7-8.

FIG. 15 illustrates another embodiment of a security hierarchy 313suitable for hosting a plurality of personalities and for adopting apersonality from the plurality of personalities while the DTC is in thefield. In this embodiment, the DTC hosts ten personalities associatedwith four banks (Bank 1, Bank 2, Bank 3, Bank 4) and three paymentschemes (Visa, Mastercard, American Express). Bank 1, Bank 2 and Bank 3use the services of a TSP to perform operations on the DTPU, while Bank4 would use its own SP-TSM to perform operations on the DTPU:

-   -   a TSP for Visa accounts has control of SSD 280 and associated        SSDs (286, 290, 294) and associated PDTPs (288, 292, 296);    -   a TSP for Mastercard accounts has control of SSD 282 and        associated SSDs (298, 302) and associated PDTPs (300, 304);    -   a TSP for American Express accounts has control of SSD 284 and        associated SSDs (306, 310) and associated PDTPs (308, 312); and    -   an SP-TSM for Bank 4 has control of SSD 314 and associated SSDs        (316, 320, 324) and associated PDTPs (318, 322, 326).

Cascade locking of the Lock SSD 206 causes all associated SSDs (280,286, 290, 294, 282, 298, 302, 284, 306, 310, 314, 316, 320, 324) to belocked, and all associated PDTPs (288, 292, 296, 300, 304, 308, 312,318, 322, 326) to be inoperable. The application selection module 225 isagain operable to activate a targeted PDTP as described above withreference to FIGS. 7-8.

FIG. 16 illustrates an embodiment of a branch 331 of a further securityhierarchy suitable for hosting a plurality of personalities and foradopting a personality from the plurality of personalities while the DTCis in the field. This security hierarchy is also suitable to adopt oneor more operating modes (contact or contactless).

The branch 331 is a child of the Lock SSD 206. The SSD 228 is controlledby Bank 1 and is a parent to SSD 330 (which is associated with a firstpersonality) and SSD 334 (which is associated with a secondpersonality).

The first personality (associated with SSD 330) is a Bank 1 Visa debitaccount personality associated with PDTP 332 which comprises contact andcontactless transaction applications.

The second personality (associated with SSD 334) is a Bank 1 Mastercardcredit account personality which has two modes of operation:

-   -   contact mode, corresponding to a transaction application group        338 (a subset of the PDTP) which includes at least one contact        transaction application; and    -   contactless mode, corresponding to a transaction application        group 342 (a subset of the PDTP) which includes at least one        contactless transaction application.

The transaction application group 338 is only operable in contact mode,and the transaction application group 342 is only operable incontactless mode. In this embodiment, both transaction applicationgroups 338, 342 are associated with the same Mastercard personality(same PAN, same expiry date, same account name etc.) and part of thesame PDTP.

One of the two operating modes can be activated (leaving the otheroperating mode inoperable) by locking one of the two transactionapplication groups 338, 342 and unlocking the other group. Making onlyone of the operating modes active enables the cardholder to operate theMastercard personality in either contact mode or contactless mode, butnot both.

Alternatively, both operating modes can be made simultaneously active byunlocking both transaction application groups 338, 342. However, Bank 1may choose not to allow both operating modes to be simultaneouslyactive, which in an embodiment is implemented by including suchinformation in the metadata associated with the personality.

In an embodiment, the DTC is operable to activate or de-activate anoperating mode by receiving an operating mode selection from thecardholder (via the user interface 83A, 83B), and using the cardholder'sselection to trigger the MCU 32 to generate a list of AIDs associatedwith the selected operating mode. The list of AIDs specifies eachtransaction application required for the selected operating mode. TheMCU is operable to generate the list of AIDs by referring to metadata(stored in an MCU registry) and to forward the AIDs to the script applet81 in the OSE 80. The script applet 81 uses the AIDs to generate scriptsto be executed in the DTPU 30.

In one method, the scripts target the application selection module 225in the DTPU which uses the Global Lock privilege to cascade lock alltransaction applications and then unlock each transaction applicationassociated with the selected operating mode (either group 338 or group342). In another method, the scripts target SSD 336 and SSD 340 witheither a lock command or an unlock command. For example, a script whichlocks SSD 336 and unlocks SSD 340 causes transaction application group338 to be locked and transaction application group 342 to be unlocked,without using Global Lock privilege.

FIG. 17 illustrates a further embodiment of a branch 351 of a securityhierarchy suitable for hosting a plurality of personalities and foradopting a personality from the plurality of personalities while the DTCis in the field. This security hierarchy is also suitable to adopt oneor more accounts from a plurality of accounts associated with apersonality. In this embodiment, each personality has accounts indifferent currencies.

The branch 351 is a child of the Lock SSD 206. The SSD 228 is controlledby Bank 1 and is a parent to SSD 330 (which is associated with a firstpersonality) and SSD 334 (which is associated with a secondpersonality).

The first personality (associated with SSD 330) is a Bank 1 Visa debitaccount personality which operates in two currencies:

-   -   US dollar transactions in contact and contactless modes,        corresponding to a transaction application group 348 (a subset        of the PDTP) with contact and contactless interfaces; and    -   Euro transactions in contact and contactless modes,        corresponding to a transaction application group 352 (a subset        of the PDTP) with contact and contactless interfaces.

In this embodiment, transaction application groups 348, 352 areassociated with the same Visa personality (same PAN, same expiry date,same account name etc.) and part of the same PDTP. One of the twocurrencies can be activated (leaving the other currency inoperable) bylocking one of the two transaction application groups 348, 352 andunlocking the other group. Making only one of the currencies activeenables the cardholder to operate the Visa personality with only one ofthe two currencies.

Alternatively, both currencies can be activated. Bank 1 may choose notto allow both currencies to be active simultaneously, which in anembodiment is implemented by including such information in the metadataassociated with the personality.

In an embodiment, the DTC is operable to operable to activate orde-activate a currency by receiving a currency selection from thecardholder (via the user interface 83A, 83B), and using the currencyselection to trigger the MCU 32 to generate a list of AIDs associatedwith the selected currency. The list of AIDs specifies each transactionapplication required for the selected currency. The MCU is operable togenerate the list of AIDs by referring to metadata (stored in an MCUregistry) and to forward the AIDs to the script applet 81 in the OSE 80.The script applet 81 uses the AIDs to generate scripts to be executed inthe DTPU 30.

In one method, the scripts target the application selection module 225in the DTPU which uses the Global Lock privilege to cascade lock alltransaction applications and then unlock each transaction applicationassociated with the selected currency. In another method, the scriptstarget each of SSD 346 and SSD 350 with either a lock command or anunlock command, without using Global Lock privilege.

The second personality (associated with SSD 334) is a Bank 1 Mastercardcredit account personality which operates in two currencies and has twoseparate modes of operation:

-   -   Australian dollar transactions in contact mode, corresponding to        a transaction application group 356 (a subset of the PDTP) which        includes at least one contact transaction application;    -   Australian dollar transactions in contactless mode,        corresponding to a transaction application group 360 (a subset        of the PDTP) which includes at least one contactless transaction        application;    -   Yen transactions in contact mode, corresponding to a transaction        application group 364 (a subset of the PDTP) with at least one        contact transaction application; and    -   Yen transactions in contactless mode, corresponding to a        transaction application group 368 (a subset of the PDTP) with at        least one contactless transaction application.

In this embodiment, transaction application groups 356, 360, 364, 368are associated with the same Mastercard personality (same PAN, sameexpiry date, same account name etc.) and are part of the same PDTP. Oneor more of the two currencies and the two operating modes can beactivated (leaving the other currencies and operating modes inoperable)by either locking or unlocking transaction application groups 356, 360,364, 368, which enables the cardholder to operate the Mastercardpersonality with a selected currency and selected operating mode.

Bank 1 may choose not to allow some currencies and operating modes to beactive simultaneously, which in an embodiment is implemented byincluding such information in the metadata associated with thepersonality.

In an embodiment, the DTC is operable to activate or de-activate acurrency selection and an operating mode by receiving a selection fromthe cardholder, and using the selections to trigger the MCU 32 tocommand the script applet 81 to generate a script to be executed by theDTPU 30 (as described above).

In one method, the scripts target the application selection module 225in the DTPU which uses the Global Lock privilege to cascade lock alltransaction applications and then unlock each transaction applicationassociated with the selected currency and operating mode, which in thisembodiment is one or more of transaction application groups 356, 360,364, 368. In another method, the scripts target each of SSDs 354, 358,362, 366 with either a lock command or an unlock command, without usingGlobal Lock privilege.

Provisioning Infrastructure

FIG. 18 shows an embodiment of a provisioning infrastructure 10 arrangedto provision the DTC 12 via a Data Assistance Device (DAD) 14 (forexample a smart phone) while the DTC and DAD are both physically remotefrom the provisioning infrastructure 10. The provisioning infrastructure10 includes a provisioning network 16, at least one issuer 18 (sometimesreferred to as an initial card issuer), a remote notification service22, a wireless communication network 24, and a mobile application portal62.

The issuer 18 in payment embodiments can be any party that authorises apayment service to be provided by the DTC 12 (in at least somenon-payment embodiments, the issuer can be the party that issues adocument such as a passport or drivers license). For example, the issuer18 may be a financial institution or a party with a banking license. Theissuer 18 also authorises the provisioning network 16 to provision theDTC 12 while the DTC is in the field. In various embodiments, the issuer18 issues the DTC 12 to a cardholder. It is also contemplated in otherembodiments that the DTC 12 can be issued by another authorized provider(sometimes referred to as an additional card issuer or distributor).However, in this specification the system will be exemplified with aninitial card issuer 18. The provisioning infrastructure 10 is shownoperating with only one issuer 18, however, in various embodiments, theprovisioning infrastructure is operable with multiple issuers (forexample, issuers for many different banks and/or financialinstitutions). In other embodiments, the provisioning network may beassociated with a single issuer.

The provisioning network 16 is operable to communicate with the DAD 14by means of the wireless communication service 24 (creating acommunication link 20) and to communicate with the DTC 12 via the DAD 14(using wireless communication link 26). The issuer 18 or its agent isoperable to communicate with the DAD 14 via the provisioning network 16and link 20. The wireless communication network 24 can be any wirelessnetwork capable of transmitting sufficient data to and from the DAD 14,and could include, for example, an internet service provider or a mobilenetwork operator.

In the illustrated embodiments, the provisioning infrastructure 10 isoperable to communicate with the DTC 12 via the DAD 14 and the wirelesscommunication network 24. However, in other embodiments, communicationswith the DTC 12 may occur Over The Wire (OTW) through a DTD, such as aPOS terminal, directly to the DTC via contact link (for example, bydipping the DTC in to the DTD) or by a contactless communication linkbetween the DTD and the DTC, for example via NFC or Bluetooth betweenthe DTD and DTC. In other embodiments, the OTW communication may be tothe DAD 14 via a contactless communication link (for example, NFC orBluetooth) and then from the DAD to the DTC 12 (for example, viaBluetooth).

In the embodiment shown in FIG. 18, the DAD 14 and the DTC 12 are linkedvia link 26 for intercommunication. In one example, the link 26 usesBluetooth (including Bluetooth Low Energy BLE). In other examples, thelink 26 uses Near Field Communication (NFC). In yet another example(described below with reference to FIG. 20), the DTC 12 includes WiFicapability which enables the DTC to connect directly to the wirelesscommunication network 24 without requiring the DAD 14 forintercommunication therebetween. However, the DAD may be employed ininitially setting up the WiFi communication between the DTC and thewireless communication network.

In alternative embodiments, the link 26 between the DAD 14 and DTC 12 isa non-wireless communication link. In one such embodiment, link 26 is acable connection between the DTC 12 and DAD 14. In another suchembodiment, the link 26 includes electrical contacts which are operableto be brought into data communication with electrical contacts on theDTC 12 (for example, contact plate 34 shown in FIG. 1B). In one version,the DAD 14 includes such electrical contacts. In another version, theDAD 14 is operable to connect via a cable to an apparatus which includeselectrical contacts operable to be brought into data communication withelectrical contacts on the DTC 12. In other alternative embodiments, thelink 26 includes both wireless and non-wireless communication links. Inone such embodiment, the DAD 14 is operable to connect wirelessly to anapparatus which includes electrical contacts and is operable to bebrought into data communication with electrical contacts on the DTC 12.

FIG. 18 also illustrates a remote notification service 22 which isoperable to provide push notifications to a mobile application 60 on theDAD 14 (for example a smart phone). For example, a push notification mayrequest the cardholder to download provisioning data to the DTC or DAD,such as digital objects which install a new personality or a firmwareupdate. Such a push notification could include a notification to thecardholder to check that the DTC is powered up and paired with the DADbefore commencing a download of digital objects. Such provisioning wouldtake place through the provisioning infrastructure 10 using theprocesses described below.

FIG. 18 also illustrates a mobile application portal 62. In oneembodiment, the mobile application portal 62 is operable to download themobile application 60 onto the DAD 14. In another embodiment, the mobileapplication portal 62 is operable to download a configuration file ontothe DAD 14. Such a configuration file may include Bluetooth keys for aspecific DTC to enable the DAD 14 to pair with the DTC 12. In anembodiment, such a configuration file is only be provided after thespecific DTC has been confirmed to be eligible to receive the download,for example by registering the DTC through the mobile application portal62.

FIG. 19 shows the same embodiment shown in FIG. 18 but illustratesfurther details of the provisioning network 16 and DAD 14. Forsimplicity, only the MCU 32 is shown within the DTC 12 and othercomponents of the DTC are omitted. The provisioning network 16 includesa first provisioning agent 36 and at least one second provisioning agent38. The provisioning agent 36 includes functions of a TSM, but providesfunctions not provided by known TSMs, including management functionswhich support the operation of the DTC 12. In the following embodiments,the provisioning agent 36 will be referred to as a DPD manager 36.

In embodiments, each provisioning agent 38 is a Trusted Service Manager(TSM) or a Tokenised Service Provider (TSP), both of which are known inthe prior art. In the following embodiments, the at least one secondprovisioning agent 38 will be referred to as a TSM/TSP 38.

The TSM/TSP 38 is trusted or managed by the issuer 18. The DPD manager36 is in data communication with the DAD 14 and the TSM/TSP 38, and theTSM/TSP is in data communication with the issuer 18. In someembodiments, the components and functions of the provisioning network 16can be provided by a single agent (provisioning agent), a single serverand/or a single site, however, it is envisaged that in most embodimentsthe various components and functions are to be provided by differentagents, albeit with some components and functions combined in a singleagent or single server. It is also possible that the issuer 18 and theprovisioning network 16 is a combined agent (combined provisioningagent), or that parts of the provisioning network are combined with theissuer.

The DPD manager 36 provides a number of important functions related tothe provisioning and operation of the DTC 12. The DPD manager 36 isoperable to generate digital objects additional to those provided by atraditional TSM/TSP 38, and to transmit such digital objects to the DTC12.

The DPD manager 36 is also operable to transmit digital objects to theDTC 12 on behalf of the TSM/TSP 38. In particular, the DPD manager 36 isoperable to receive digital objects provided by the TSM/TSP 38 and totransmit such digital objects to the DTC 12. The DPD manager 36 providesthis function (the transmission of digital objects on behalf of theTSM/TSP 38) because provisioning agents of the prior art, such asTSM/TSP 38, are not suitable for provisioning a digital payment devicesuch as a DTC 12. One of the reasons is that a prior art TSM/TSP 38 isarranged to communicate directly with a digital wallet on a mobiledevice, without communicating through an intermediary device such as theDAD 14. Also, a prior art TSM/TSP 38 does not provide routinginformation to instruct the MCU 32 to provide the digital objects to asuitable component on the DTC. Also, a prior art TSM/TSP 38 is onlyknown to provision contactless payment instances. Further, a prior artTSM/TSP 38 is only known to provide metadata (such as the payment schemename, branding, account name, last four digits of the PAN) to a singledevice (a wallet on mobile device), whereas embodiments of the presentinformation provision two devices with metadata, namely the DTC 12 andDAD 14.

In the embodiment in FIGS. 18-19, the DPD manager 36 is operable totransmit digital objects to the DTC 12 via the DAD 14 via link 26 (forexample using Bluetooth for communications between the DTC 12 and theDAD 14), and in the embodiment shown in FIG. 20 the DPD manager 36 isoperable to transmit digital objects directly to the DTC 12 via a WiFicommunication link 64. Such digital objects are provided to at least oneof the MCU 32 and DTPU 30 of the DTC 12. In the embodiment in FIGS.18-19, providing the digital objects to the MCU and/or DTPU involvesestablishing the communications links 20, 26 with the DTC 12 via the DAD14. In the embodiment in FIG. 20, providing the digital objects to theMCU and/or DTPU involves establishing the communication link 64 with theDTC 12.

In an embodiment, the DPD manager 36 includes routing information (forexample, a header) with each digital object transmitted to the DTC vialink 20, link 26 or link 64. In an embodiment, the routing informationincludes information indicative of an intended destination of thedigital object. In an embodiment, the information indicative of anintended destination of the digital object specifies a component of theDTC, for example the DTPU. The MCU is operable to read the routinginformation and provide the digital object to the specified component ofthe DTC (as specified in the routing information). For example, therouting information can be operable to instruct the MCU to forward adigital object to the DTPU, or in another example, store the digitalobject in the MCU. The DPD manager 36 also includes routing informationwith any digital object provided by the TSM/TSP 38, and transmits suchdigital object(s) together with the routing information to the DTC 12.

In an embodiment, the DPD manager 36 is also operable to maintain arecord of the state of the DTC 12, including a record of eachpersonality installed on (hosted by) the DTC 12, and characteristics ofthe DTC 12, for example the device model. In an embodiment, the DPDmanager 36 is operable to request the DTC 12 to provide informationindicative of the state of the DTC. The DPD manager 36 is also operableto receive requests from the cardholder for a new personality to beinstalled on the DTC 12 while the DTC 12 is in the field. The DAD 14 isoperable to transmit each such cardholder request to the DPD manager 36,and the DPD manager 36 is operable to forward each such cardholderrequest to the TSM/TSP 38, which in turn is operable to forward eachsuch cardholder request to the issuer 18. In an embodiment, the DPDmanager 36 is operable to include additional information in the requestto the issuer 18, for example information which specifies aspects of thepersonality to be installed, including information regarding therequired operation mode of the personality (contact, contactless, orboth). In another embodiment, the issuer 18 provides an online facilityfor the cardholder to submit the request directly without using the DAD14. If the issuer 18 approves the cardholder's request for a newpersonality to be installed, the issuer 18 initiates a process in whichthe DPD manager 36 and the TSM/TSP 38 both provide digital objects forinstallation on the DTC 12.

In the embodiments shown in FIGS. 18-20, only one issuer 18 and oneTSM/TSP 38 are depicted in the provisioning infrastructure 10, but itshould be understood that the provisioning infrastructure 10 can includea plurality of issuers and the provisioning network 16 can include aplurality of provisioning agents. In one embodiment, the provisioningnetwork 16 includes a plurality of TSMs. In another embodiment, theprovisioning network 16 includes a plurality of TSPs. In anotherembodiment, the provisioning network 16 includes at least one TSM and atleast one TSP. Each TSM (which may also be referred to as a ServiceProvider TSM or SP-TSM) is usually managed directly by a separate issuer18. A TSP is generally a service provided by another party such as apayment scheme (for example Visa or Mastercard) a on behalf of theissuer 18. In an embodiment, the provisioning infrastructure 10 includesat least one issuer for each TSP, and includes a separate TSP for eachpayment scheme supported by the provisioning infrastructure.

The TSM/TSP 38 includes a key manager 42 and is operable (amongst otherfunctions) to negotiate SSD cryptographic key management on the DTC 12on behalf of the issuer 18. Each key manager 42 is operable to issue SSDkeys 44 to the DTC 12. The key manager 42 may sometimes be referred toas, or the functions of a key manager may be incorporated into, asecurity domain manager.

Some DAD Component Details and Mobile Application Setup

In the embodiment shown in FIGS. 18-20, the DAD 14 is a smartphone,however, in other embodiments, the DAD can be any suitable device, suchas a PC, a tablet PC, or other types of mobile computing devices. In yetother embodiments, the DAD may be a Digital Transaction Device (DTD),such as an Automatic Teller Machine (ATM), which has been suitablyadapted to provide the functionality required of the DAD in embodimentsof this invention.

In other embodiments, it is contemplated that the functions required ofthe DAD 14 in the present invention could be performed on a DTC ifconfigured with functionality to communicate with the provisioningnetwork 16 (likely using WiFi or similar technology). Such a DTC wouldalso need to be equipped with suitable processing, memory and a powersource to perform the required functions as performed by the DAD inembodiments of the present invention. Thus, the DAD 14 is an optionalcomponent for implementing embodiments of the present invention.

The DAD has software installed, referred to as a DAD gateway 48, whichenables the DAD 14 to act as a bridge between the provisioninginfrastructure 10 and the DTC 12. The DAD gateway 48 is operable tocommunicate with the provisioning infrastructure 10 via link 20, andwith the DTC 12 via link 26. The DAD gateway 48 provides functionalitywhich may not be visible to the cardholder of the DAD 14, unlike themobile application 60 which is visible to cardholders. The DAD gateway48 and mobile application 60 can be part of the same softwareinstallation, but as they provide different types of functionality theywill be described here as though they are separate software items.

The DAD gateway 48 and mobile application 60 may be requested anddistributed by another authorized party. In some embodiments, the DADgateway 48 and mobile application 60 are provided to the DAD 14 onlyupon confirmation that the user of the DAD (or the DAD itself) isauthorized to receive the mobile application, wherein the DAD providesconfirmation of the DAD identity (for example, the International MobileEquipment Identity (IMEI) of the DAD if a smartphone). Typically the DADuser will be the same person as the DTC cardholder. In otherembodiments, the confirmation of authorization includes confirming theDTC 12 identity, which may include one or more of a unique serial numberfor the DTC, a Bluetooth ID, a unique identifier for a DTPU on the DTCand other unique identifiers which either singly or in combinationuniquely identify the DTC or components thereon. In some embodiments,the confirmation of authorization includes a combination of a DADidentifier and one or more DTC identifier(s).

In at least some embodiments, the DTC 12 is operable to take part in apersonality installation process which is operable to install a newpersonality on the DTC while the DTC is in the field. In such a process,the DPD manager 36 transmits digital objects to the DAD 14 and DTC 12,the digital objects including scripts and metadata associated with thepersonality. Examples of metadata associated with a personality includethe scheme name, the issuer name, the cardholder's name, the full PAN,the last four digits of the PAN, the expiry date, and the CVV. Inembodiments, at least some of the metadata is stored on both the DAD 14and the DTC 12.

In the embodiment shown in FIGS. 18-19, the DPD manager 36 is operableto forward digital objects for the installation of a new personality tothe DAD 14, and the DAD 14 is operable to forward the digital objects tothe DTC 12. The DTC 12, after processing the digital objects, isoperable to forward at least some of the metadata (contained within thereceived digital objects) back to the DAD 14 for installation thereon.

In the embodiment shown in FIG. 20, the DTC 12 includes a WiFicommunication module 88 (shown in FIG. 1B) and the DTC is operable tocommunicate with the DPD manager 36 via link 64 which uses wirelesscommunication network 24. The DPD manager 36 is operable to forwarddigital objects to install a new personality directly to the DTC 12 vialink 64, bypassing the DAD 14. In an embodiment, the cardholder triggersthe download such digital objects to the DTC, for example by pressing abutton on the DTC. The DTC 12 and DAD 14 in FIG. 20 are also operable tocommunicate via link 26 (as in FIGS. 18-19), for example via Bluetoothor NFC. The DTC 12, after processing the received digital objects, isoperable to forward at least some of the metadata (contained within thereceived digital objects) back to the DAD 14 for installation thereon.

The process of installing a new personality on the DTC 12 can betriggered in different ways. In an embodiment of a personalityinstallation process, the process is triggered when a cardholder usesthe mobile application 60 on the DAD 14 to select a new personality andrequest installation of the personality on the DTC. In an embodiment,the personality is selected from a list of personalities available fordownload to the cardholder. This list of personalities may be determinedby the issuer 18, based on accounts held by the cardholder.

The DAD gateway 48 on the DAD 14 is operable to transmit the personalityinstallation request to the issuer 18 and/or the DPD manager 36. In analternative embodiment of a personality installation process, theprocess of installing a new personality on the DTC 12 begins when acardholder engages a user interface on the DTC 12 (not shown) to selecta new personality and requests installation of the personality on theDTC. The DTC 12 is operable to transmit the personality installationrequest to the DAD gateway 48 on the DAD 14, and the DAD gateway 48 isoperable to transmit the installation request to the issuer 18 and/orthe DPD manager 36. If a cardholder's personality installation requestis approved by the provisioning infrastructure 10 (typically by theissuer 18 and/or the DPD manager 36), the DPD manager 36 is operable tobegin the installation process.

Throughout this specification and the claims which follow, unless thecontext requires otherwise, the word “comprise”, and variations such as“comprises” and “comprising”, will be understood to imply the inclusionof a stated integer or step or group of integers or steps but not theexclusion of any other integer or step or group of integers or steps.

The reference to any prior art in this specification is not and shouldnot be taken as an acknowledgement or any form of suggestion that theprior art forms part of the common general knowledge.

What is claimed is:
 1. A Digital Transaction Processing Unit (DTPU)comprising one or more transaction applications operable for a digitaltransaction with a Digital Transaction Device (DTD), each of the one ormore transaction applications being associated with identifyinginformation, the identifying information being capable of identifying asubset of at least one transaction application within the one or moretransaction applications, wherein the DTPU is operable, when conductinga transaction with the DTD, to communicate to the DTD the identifyinginformation associated with one of the one or more transactionapplications involved in the transaction.
 2. A DTPU in accordance withclaim 1, wherein the identifying information includes a tokenizedprimary identifier.
 3. A DTPU in accordance with claim 2, wherein thetokenized primary identifier is a tokenized Personal Account Number(PAN).
 4. A DTPU in accordance with claim 1, wherein the identifyinginformation includes a sequence number.
 5. A DTPU in accordance withclaim 1, wherein the identifying information includes an AID.
 6. A DTPUin accordance with claim 1, wherein the identifying informationcorresponds to a transaction type.
 7. A DTPU in accordance with claim 6,wherein the transaction type is a currency in which the associatedtransaction application is operable to conduct transactions.
 8. A DTPUin accordance with claim 6, wherein the transaction type is defined by auser.
 9. A DTPU in accordance with claim 6, wherein the transaction typecorresponds to a user-defined transaction category.
 10. A DTPU inaccordance with claim 6, wherein each transaction type corresponds witha different account type hosted by a financial institution.
 11. A DTPUin accordance with claim 10, wherein the financial institutionassociates each different account type with the primary identifier forthe one or more transaction applications.
 12. A DTPU in accordance withclaim 1, wherein the subset of at least one transaction applicationincludes a contact transaction application and a contactless transactionapplication.
 13. A DTPU in accordance with claim 1, wherein each of theone or more transaction applications is operable to conduct atransaction with a payment scheme, the one or more transactionapplications being operable to conduct a transaction with the samepayment scheme.
 14. A DTPU in accordance with claim 1, wherein each ofthe one or more transaction applications is associated with acorresponding primary PAN, the one or more transaction applicationsbeing associated with the same corresponding PAN.
 15. A DTPU inaccordance with claim 1, wherein the one or more transactionapplications are associated with a Personalized Digital TransactionPackage (PDTP), the DTPU being operable to host one or more PDTPs, eachPDTP hosted by the DTPU being associated with a different primary PAN.16. A DTPU in accordance with claim 15, wherein each hosted PDTP isassociated with a corresponding personality hosted by the DPD.
 17. ADTPU in accordance with claim 1, wherein each of the one or moretransaction applications is associated with a corresponding personalityhosted at least in part by the DPD, the one or more transactionapplications being associated with the same personality.
 18. A DTPU inaccordance with claim 1, wherein the one or more transactionapplications comprises a plurality of transaction applications.
 19. Asystem for conducting digital transactions, the system comprising: aDigital Payment Device (DPD) comprising a Digital Transaction ProcessingUnit (DTPU) comprising one or more transaction applications operable fora digital transaction with a Digital Transaction Device (DTD), each ofthe one or more transaction applications being associated withidentifying information, the identifying information being capable ofidentifying a subset of at least one transaction application within theone or more transaction applications, wherein the DTPU is operable, whenconducting a transaction with the DTD, to communicate to the DTD theidentifying information associated with one of the one or moretransaction applications involved in the transaction; and a transactionprocessing system which includes the DTD and is operable to conductdigital transactions with the DPD.
 20. A method of operating a DigitalTransaction Processing Unit (DTPU) including one or more transactionapplications operable for a digital transaction with a DigitalTransaction Device (DTD), the method comprising: associating each of theone or more transaction applications with identifying information, theidentifying information being capable of identifying a subset of atleast one transaction application within the one or more transactionapplications, communicating to the DTD the identifying informationassociated with one of the one or more transaction applications involvedin the digital transaction.